Stacks

A stack groups services that belong together, such as a website and its database, into one reviewed deployment configuration. Define the services visually or with supported Compose YAML, choose an environment and an existing resource pool, review the changes, and deploy.

Each service becomes an Infralane application with its own deployments, logs, settings, and storage. The stack coordinates their deployment order and keeps their shared configuration together.

Stacks, applications, and templates

Concept	What it provides	Use it for
Application	One service and its release history	A standalone workload
Stack	One to 20 services on one pool	Related services deployed together
Environment	A named context inside a project	Organizing production or staging stacks
Template	A reusable starting configuration	Deploying a prepared application stack

Deploying a template creates a stack. Editing that stack changes your installation; it does not change the template or other customers’ installations. Read Templates overview for the public catalog and publishing workflow.

Where a stack lives


Workspace
└── Project
    ├── production environment
    │   └── store stack → selected resource pool
    │       ├── wordpress application
    │       ├── database application
    │       └── stack-specific network and named volumes
    └── staging environment
        └── store stack → selected resource pool
            ├── separate applications
            └── separate network, named volumes, and private inputs

An environment belongs to one project. A stack belongs to one environment and uses one resource pool from that project. Its name must be unique within the environment. Two environments can use the same pool; their applications still share that server’s capacity.

An existing stack’s name, environment, and pool cannot be changed in the stack editor. To target another environment or pool, create a configuration copy and plan data migration separately.

Sources and configuration

The visual builder supports container images and Git repositories built with a Dockerfile, including a different repository or branch for each service. Custom stacks can reference private images through workspace credentials granted to the project.

The Visual builder and Code views edit the same configuration. Use Code for advanced settings and importing supported Compose YAML or JSON. Infralane validates a bounded Compose subset; it does not run an arbitrary Docker Compose project or silently discard unsupported fields.

Public registry templates have additional restrictions: reviewed public images pinned to digests, declared architectures, setup inputs, and maintenance documentation. Source builds and private image credentials belong in custom stacks.

Deployment and isolation

Dependencies control service deployment order. Add explicit health checks when a dependent service needs its database ready first.
Services use their service names as private hostnames inside the same stack on the selected pool. Another stack does not join that private network, even in the same environment.
Public HTTP routing is enabled per service. Private TCP/UDP ports do not become server ports merely because they are declared.
Named volumes are scoped to the stack. A copy receives separate volume identities and does not inherit data.
Saved runtime inputs are encrypted in stack revisions and masked in the editor. Configuration exports retain references instead of resolved environment values.

Stack deployment is sequential, not an all-or-nothing transaction across running containers. A later failure can leave earlier services running. Stateful deployments can have downtime. Inspect each service before retrying or planning recovery.

Capacity, cost, and responsibility

Deploying a stack uses the pool you select. It does not purchase a server, resize a pool, or reserve additional infrastructure. Review the combined CPU and memory allocations, existing workloads, storage growth, and image architecture before deployment.

Resource-pool charges follow your existing server and billing arrangement. Template requirements are a tested baseline, not a forecast of your production workload. Software licenses and external dependencies may have their own costs; read the template’s requirements.

Database administration, independent backups, restore testing, and major-version upgrades remain your responsibility. Named volumes preserve files across service deployments; they are not backups or enforced storage quotas.

Start here

Deploy a stack: prerequisites, visual editing, a complete Compose example, and deployment review.
Compose reference: supported fields, private inputs, networking, resources, and limits.
Environments and copies: create staging configuration without copying production credentials or data.
Operate and update stacks: logs, database connections, exports, updates, and deletion.
Troubleshooting: recover from validation, deployment, health, and connection failures.