Container configuration
Configure images, commands, environment variables, ports, and storage.
Image and command
A service uses a container image reference and an optional command array. Pin an image digest when reproducibility matters. The image must be compatible with the selected runtime and provide your dependencies.
The command accepts up to 32 arguments, each up to 4,096 characters. The platform passes the configured command to the runtime; do not assume shell expansion unless you explicitly invoke a shell in your image.
Environment variables
Environment names use letters, digits, and underscores, beginning with a letter or underscore. Up to 64 values are accepted, each up to 8,192 characters. Service reads return environment names, not secret values.
A configuration update with environment replaces the entire environment map. Omit the field to keep existing values. Do not place API keys in images, templates, command arguments, screenshots, or version control.
HTTP port
httpPort defaults to 8080. Set it to null when no HTTP server is exposed. Valid ports are 1024–65535 except 9090, which is reserved by the runtime. Your application must listen on the configured port and an appropriate interface.
Disk and workspace
| Setting | Range | Default |
|---|---|---|
| Container disk | 5–500 GB | 20 GB |
| Workspace volume | 10–4,096 GB | 20 GB |
| Idle sleep | 1–1,440 minutes, or null | 15 minutes |
The container disk is distinct from the persistent /workspace mount. Attach independent storage with volumeId or create it with volumeMode: "independent". Storage lifecycle.
Update safely
Read the current revision and send only intended fields in the patch object. Image, command, port, or environment changes can restart the service. Review state and logs after an update.
Image startup requirements
The current built-in custom-container contract expects an OCI image with /bin/sh, OpenSSH, and coreutils. Use a catalog starter when you need the preconfigured runtime, and check image compatibility before choosing a minimal or distroless base image. The platform does not automatically make every Docker image compatible.
Private image access
The current preview source supports account-owned pull credentials for one exact, fully qualified repository. Configure access in Settings; matching services and templates select it automatically. Credentials go to the runtime's image-pull mechanism rather than your application environment.
A private-image launch requires the coordinated control-plane and gateway version. See Private container images for repository scope, rotation, and removal behavior.