Deploy a stack

Use this guide to deploy a custom stack or an available starting configuration. To install an exact published template release, follow Deploy a template.

Before you begin

You need:

• A selected workspace and project, with project write permission.
• An active resource pool in that project, with enough available capacity for all services.
• Crane updated to support stack deployments. If the pool rejects the capability check, update Crane before retrying.
• Images compatible with the pool architecture. Dockerfile source builds currently require amd64; an ARM pool needs compatible prebuilt images.
• Access to any private Git repository or project-granted registry credential the services use.

Creating an environment or reviewing a configuration does not deploy applications. The final deployment action queues work on the chosen pool.

1. Choose the stack location

1. Open Stacks in the dashboard and select Deploy stack.
2. Enter a Stack name. Start with a lowercase letter and use up to 40 lowercase letters, digits, or hyphens. The name must be unused in the selected environment.
3. Choose an Environment, or select Create environment and enter a name such as production.
4. Choose a Resource pool from the current project.
5. Choose Custom stack or an available Starting configuration.

Starting configurations depend on the current catalog. Existing built-in configurations include WordPress and database services; a built-in entry is not proof that a public registry release has been published. Public inventory is shown in Templates.

2. Add and configure services visually

In Advanced service configuration, open Visual builder. Choose a Service to add, add it, then select the service to configure it.

A dependency orders deployment; it does not create a database connection string. Set the application’s connection variables separately. Use the database service name, not localhost, for a connection from another container.

Renaming a draft service updates dependency references, but private URLs cannot be rewritten safely. Update hostnames and connection inputs yourself. Deployed services must be removed through their applications before removing them from stack configuration.

3. Import Compose instead

Choose Code to paste Compose YAML or JSON. The same document is available in Visual builder afterward. Correct syntax errors in Code if the visual editor cannot read the document.

This complete example defines a WordPress service, a private MariaDB database, a health dependency, and two persistent volumes. It is an illustrative custom configuration based on the built-in starting configuration, not a published registry release or a production sizing recommendation. It allocates 1 CPU core and 1,024 MB memory in total; allow additional capacity for the server and other workloads. Review upstream versions and backup requirements before use.

services:
  database:
    image: mariadb:11.4
    environment:
      MARIADB_DATABASE: "app"
      MARIADB_USER: "app"
      MARIADB_PASSWORD: "${DATABASE_PASSWORD}"
      MARIADB_ROOT_PASSWORD: "${DATABASE_ROOT_PASSWORD}"
    expose:
      - "3306"
    volumes:
      - database-data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 5s
      timeout: 3s
      retries: 10
    x-infralane:
      cpu: 0.5
      memory_mb: 512
  wordpress:
    image: wordpress:php8.3-apache
    depends_on:
      database:
        condition: service_healthy
    environment:
      WORDPRESS_DB_HOST: "database:3306"
      WORDPRESS_DB_NAME: "app"
      WORDPRESS_DB_USER: "app"
      WORDPRESS_DB_PASSWORD: "${DATABASE_PASSWORD}"
    volumes:
      - wordpress-content:/var/www/html
    x-infralane:
      http_port: 80
      cpu: 0.5
      memory_mb: 512
volumes:
  database-data: {}
  wordpress-content: {}

database has no public HTTP port, and expose does not make port 3306 public. WordPress receives HTTP routing to container port 80. Both services use the same DATABASE_PASSWORD input, so the client and server configuration agree.

Use the Compose reference when adapting an existing file. Remove unsupported settings such as ports, env_file, custom networks, host mounts, and deploy; replace their intent with supported settings where available.

4. Supply private inputs

The Private inputs section lists references found in the configuration. For the custom example, supply DATABASE_PASSWORD and DATABASE_ROOT_PASSWORD, or use Generate value for each. These are separate credentials; do not use a real password as a literal in the YAML.

Some starting configurations and registry inputs generate passwords when left blank. A new custom reference without a default requires a value; it does not acquire automatic generation merely because its name contains PASSWORD.

For an existing stack, an empty input field keeps its saved value. For a configuration copy, provide new values: saved inputs are not copied. See private input syntax.

5. Review before deploying

Select Review deployment. Review checks configuration and creates a plan without changing applications. Inspect:

• Stack, environment, and resource pool.
• Each service’s create or update action.
• Image or Dockerfile source, repository and branch, and registry access.
• Public HTTP ports, named volume counts, dependencies, CPU, and memory.
• Warnings about shared pool capacity, persistent data, downtime, and partial failure.

The plan expires after 15 minutes. Editing the configuration invalidates the displayed review. If another session changes the stack, review the latest configuration again.

6. Deploy and verify

Select Deploy stack. An update uses Save and redeploy stack. Deployment continues after you leave the page.

The stack details page shows the ordered services, current service, completed services, and operation message. Open each application for its deployment output and logs. A successful operation is labeled Completed; verify the application itself before directing production traffic to it.

For the example, open the WordPress application’s generated URL and complete its administrator setup. The database initialization password is not a WordPress administrator account. Add a custom domain after confirming the site works.

If the final request loses its response, use Check and retry reviewed deployment. That control retains the request identity to check an already accepted deployment. Do not create a second stack just because the first response was uncertain. Follow stack troubleshooting for Unknown or Failed outcomes.