New · Release 2026.04, Multi-tenant audit exports & SLA dashboards now liveSee changelog →
Infrastructure
InfroStack: guided server provisioning and stack building
Plan a new server or stack with a catalog, validation and recommendations — a guided wizard that helps size and shape infrastructure before you build it.
Product illustration · sample data
Infrastructure / Live
142/142 healthy
CPU avg
34%
Memory avg
62%
api-prod-01.acme.io98ms
db-primary.acme.io12ms
worker-eu-03.acme.ioSSL expires 14d
Product proof
Already live in the product
Backed by app modules
Running in production today: the stack catalog, configuration validation, and sizing recommendations.
Protected app route: /servers
How it works
Built around real workflows
Highlights below describe capabilities already present in the protected app behind this page.
Server and stack catalog
Configuration validation
Sizing recommendations
Guided setup flow
Workflow
What teams can do here
Step 1
Pick a stack
Step 2
Validate the configuration
Step 3
Review recommendations
Step 4
Proceed to build
How it works
How it works
01
Choose your stack
Pick frontend, backend language and framework, database, cache, search, reverse proxy, SSL and deployment strategy from a version catalog. Each version is tagged latest, LTS, active, stable, beta or end-of-life.
02
Validate the combination
The compatibility engine checks the selection, warns on end-of-life versions and returns errors and warnings before you commit to anything.
03
Review recommendations
Opinionated recommendations by use case help you size and shape the stack, with an AI assistant available for questions grounded in the same catalog.
04
Generate starter artifacts
The wizard produces a Dockerfile, a docker-compose.yml and a .env.example from your selection — opinionated starter files, not full production manifests — and saves the spec as draft, validated or created.
Example
A worked example
Say a fifteen-developer product team is scoping its next internal service. In InfroStack they select a Node.js backend, PostgreSQL, Redis, an nginx reverse proxy and Let's Encrypt SSL. The validator flags the chosen runtime line as nearing end-of-life and points at the LTS tag; they switch before a single container exists. With the selection saved as validated, the wizard emits a Dockerfile, a docker-compose.yml wiring app, database, cache and proxy together, and a .env.example listing the connection strings to fill — a scaffold the team refines instead of a blank page, and a spec the next hire can read.
FAQ
Frequently asked questions
Does this actually provision live servers?
No. InfroStack is a planning and specification wizard. It helps you choose and validate a stack and generates starter config files; it does not stand up real infrastructure. A saved stack can optionally be linked to a deployment target for later use.
What files does the wizard generate?
A Dockerfile tailored to the backend runtime, a docker-compose.yml that wires the app together with your database, cache, search and reverse proxy, and a .env.example with connection strings and secret placeholders. They are opinionated starters, not complete production manifests.
How does it stop me picking an outdated version?
Every technology version in the catalog carries a status — latest, LTS, active, stable, beta or end-of-life — and the compatibility engine flags end-of-life choices and other conflicts as warnings and errors when you validate.
What deployment targets can a stack aim at?
The wizard understands targets such as VPS, Docker, Kubernetes and cloud runtimes (AWS, GCP, Azure and platforms like Railway, Render and Fly.io), and can associate a saved stack with a deployment target for a downstream pipeline.
Is a saved stack shared across tenants?
No. Every server stack is tied to your organization, so specifications and their generated artifacts stay within your tenant.
Can we keep more than one stack specification?
Yes. Each specification is saved as its own record with a draft, validated or created status, so a team can maintain separate stacks for separate services and revisit or revise any of them later.
Pick versions from a status-tagged catalog, let the compatibility engine veto end-of-life choices, and walk away with a Dockerfile, compose file and .env scaffold your team can actually start from.