Compose reference

Infralane compiles supported Compose YAML or JSON into application deployments. Unsupported fields fail validation. A file that runs with the Docker Compose CLI may need changes before it can be imported.

Start with the complete stack example. The snippets below show individual configuration patterns.

Document structure and limits

Keys must be unique strings. YAML anchors, aliases, merge keys, multiple Compose files, and overly complex documents are not supported. The dashboard’s stack name and environment selection determine stack identity; top-level Compose name is not a way to move or rename an existing stack.

Supported service fields

Long-running services use the supported restart policy. A dependency with service_completed_successfully is not supported; configure one-off or scheduled work separately from stack startup.

Infralane service settings

All extension settings belong under the individual service’s x-infralane mapping.

mem_limit, when present, takes precedence over memory_mb. 1g converts to 1,024 MB. Configure an allocation once where possible to avoid conflicting settings. Pool capacity and application allocation validation still apply; an importer limit is not a promise that a selected server can provide that amount.

Images and private registry access

Use a literal image reference. References cannot contain whitespace or ${INPUT} substitutions. For reproducible deployments, choose a digest you have verified for your workload and architecture. Public registry templates require reviewed digests; a custom stack can also use a tag.

For private images, choose the saved pull credential in Visual builder or reference its ID through x-infralane.registry_credential. The credential must be usable for that image and granted to the current project. Credentials remain in the workspace integration store and are checked again during deployment. Never put a registry username, password, or access token in the image reference or YAML.

See Private container registries for setup, grants, and rotation.

Dockerfile source builds

This illustrative service builds a repository subdirectory:

services:
  api:
    build:
      context: ./services/api
      dockerfile: Dockerfile
    x-infralane:
      repository: https://github.com/example/example-app
      branch: main
      http_port: 3000
      cpu: 0.5
      memory_mb: 512

Replace the example repository with your actual source. Paths must be safe relative paths. Host paths, remote build contexts, and build arguments are not supported. Without a per-service repository or branch, the build uses the Default Git repository and Default Git branch configured in Code. The default branch is main.

Private GitHub access uses the workspace GitHub integration. Use HTTPS URLs without embedded credentials, query strings, or fragments. Dockerfile builds require a compatible amd64 pool. Public registry templates do not support source builds.

Private inputs

Reference runtime values using whole-value placeholders:

environment:
  DATABASE_URL: "${DATABASE_URL}"
  APP_MODE: "${APP_MODE:-production}"
  API_TOKEN: "${API_TOKEN:?Provide an API token}"

Input names use uppercase letters, digits, and underscores and start with an uppercase letter or underscore. Host environment inheritance and .env file loading through env_file are disabled. Quote numeric and boolean environment values: "3000" and "true", not YAML numbers or booleans.

An environment value containing an input must be a single complete reference. For example, postgresql://app:${PASSWORD}@database/app is rejected. Supply the entire URL privately as ${DATABASE_URL}, or use a template’s derived database URL input.

Literal environment values are normalized into private references when the stack is saved. That protects resolved runtime values in configuration exports. It does not make arbitrary text in descriptions, commands, or repository URLs safe for credentials. Keep secrets in private input fields from the start.

Saved inputs are reused when omitted during an edit. The dashboard omits empty replacement fields, so leaving one blank keeps the existing value. A configuration copy does not copy saved inputs. Defaults and generated template inputs can resolve again; other required values must be supplied.

Commands and runtime shell variables

String commands are split into arguments; they do not implicitly start a shell. Prefer an explicit argument list. Use /bin/sh -c when shell expansion is required and the image provides that shell.

services:
  cache:
    image: redis:7.4-alpine
    environment:
      REDIS_PASSWORD: "${REDIS_PASSWORD}"
    command:
      - /bin/sh
      - -c
      - 'exec redis-server --appendonly yes --requirepass "$${REDIS_PASSWORD}"'
    expose: ["6379"]
    volumes: ["cache-data:/data"]
volumes:
  cache-data: {}

Supply REDIS_PASSWORD through Private inputs for this custom example. Private ${INPUT} interpolation in commands, entrypoints, and health-check arguments is rejected. $${REDIS_PASSWORD} passes a reference to the runtime environment instead of inserting the password into the stored command. Review application output too; an application can still print its own environment values.

Dependencies and health checks

depends_on:
  database:
    condition: service_healthy

The referenced service must exist, cannot be itself, and must declare an explicit healthcheck when using service_healthy. Circular dependencies are rejected. Infralane submits services sequentially in dependency order and waits for a successful application deployment before advancing. A health check allows a service deployment to check container readiness; dependencies do not continuously monitor or automatically restart other services afterward.

healthcheck:
  test: ["CMD-SHELL", 'pg_isready -h 127.0.0.1 -U "$${POSTGRES_USER}" -d "$${POSTGRES_DB}"']
  interval: 5s
  timeout: 3s
  retries: 10
  start_period: 10s

This check requires a PostgreSQL image containing pg_isready and the corresponding environment variables. CMD runs arguments directly; CMD-SHELL takes one nonempty shell command. disable and NONE checks are not supported.

Durations use whole milliseconds, seconds, or minutes, such as 1000ms, 5s, or 1m, and must resolve to whole seconds in range. Read the service’s logs when a check fails; increasing the timeout does not fix an incorrect command or missing database configuration.

Networking

• Without http_port, a service is private by default.
• expose: ["5432"] declares a private port; it does not publish port 5432 on the server.
• x-infralane.http_port configures HTTP routing to the container. Use the application’s Domains page for a custom hostname.
• Use a service name such as database or cache as the hostname from another service in the same stack on the same pool.
• Custom Compose networks, host networking, and Compose ports mappings are not supported.

For deliberately public TCP/UDP services, review the separate networking workflow. Keep databases private unless you have a specific access requirement and understand the exposure.

Persistent volumes

Declare every volume at the top level, then mount it using volume-name:/absolute/container/path. The container path cannot be / or contain parent traversal. Use the path expected by that image and version.

Host bind mounts, external volumes, driver options, long-form mounts, and :ro suffixes are not supported by the stack importer. Identical logical volume names in different stacks resolve to different Docker volume identities. Within a stack, services can reference the same declared volume; only share a data directory when the software supports concurrent access.

Redeploying with the same stack and volume name retains the volume identity. Renaming a volume or creating another stack creates a different identity. Removing a mount or deleting an application retains the old Docker volume; it does not migrate or back up its contents. Declared sizes are not enforced filesystem quotas. Read Volumes and backups.

Common unsupported settings

Expect validation errors for ports, env_file, networks, network_mode, container_name, privileged, devices, cap_add, Compose secrets or configs, deploy, build arguments, profiles, host mounts, and Docker socket mounts. Do not delete a rejected field without understanding how its absence affects the application.

For background on the broader Compose format, see Docker’s service reference  and interpolation reference . Those describe Docker Compose; the supported Infralane contract is the subset documented here.