Troubleshoot a stack
Start with the stack’s Deployment progress message. Identify the current service, open its application, and inspect the deployment and runtime logs. A stack operation can fail after earlier services have deployed, so check the actual state of every affected service.
Configuration will not review
| Message or symptom | Likely cause | Recovery |
|---|---|---|
| Unsupported Compose fields | The document uses settings outside the importer contract | Follow the Compose reference; adapt the behavior instead of assuming the field is ignored |
| YAML syntax error, duplicate keys, or aliases | Invalid indentation, repeated fields, or YAML reuse features | Correct Code view; expand anchors and aliases explicitly |
| Missing named input | A required runtime reference has no value | Provide it in Private inputs, or use Generate value if a suitable generated value is appropriate |
| Environment values must be strings | YAML interpreted a value as a boolean or number | Quote it, such as "true" or "5432" |
| Composed environment value rejected | A URL mixes literal text and ${PASSWORD} | Supply the entire URL through a single private input |
| Invalid or circular dependency | A service is missing, depends on itself, or forms a cycle | Correct the dependency graph; add a real health check before selecting service_healthy |
| Invalid named volume | Undeclared volume, host path, options, or unsupported mount syntax | Declare a plain volume and use name:/absolute/container/path |
| Service removal rejected | A deployed application still exists for the removed declaration | Review its data and delete the application explicitly before updating the stack |
| Stack name already used | The same name exists in the environment | Open that stack or choose another name for a new deployment |
The visual editor keeps your code when it cannot parse a document. Switch to Code, fix the error, and return to Visual builder. Do not discard a draft just to clear a validation message.
Review expired or configuration changed
A review expires after 15 minutes. Editing invalidates it, and a stack changed by another session cannot be applied from an older review. Reopen or refresh the stack, compare current settings with your intended change, and select Review deployment again.
An already applied review cannot be used for a different change. Inspect the resulting stack before creating another review. If the response to the final action was lost, use the existing Check and retry reviewed deployment control to preserve its request identity.
Pool cannot accept deployment
- Crane update required: follow server maintenance, update the connected server, and retry after its connection recovers.
- Pool inactive, deleting, or billing restricted: resolve the pool’s displayed state or billing restriction before deployment. A stack does not reactivate or resize it.
- Insufficient capacity: inspect combined CPU and memory allocations and existing applications. Choose suitable capacity; template minimums alone do not account for all other workloads.
- Architecture mismatch: select a pool with a template’s declared tested architecture. Custom images must also match the actual server. Git/Dockerfile builds currently require amd64.
- Project access changed: restore the required project permission or ask an authorized member to review and deploy. Permission is checked again while services are processed.
Image pull or source build failed
Check the exact image reference or repository and branch recorded for the failed service. Verify that the image exists and supports the pool architecture. Private image pulls require a valid workspace credential granted to the project and suitable for that registry path; see registry recovery.
For source builds, check GitHub installation access, the HTTPS repository URL, Dockerfile path, and build context. Do not add credentials to the repository URL. Open the service’s build logs for the actual compiler or image-build failure.
A database never becomes healthy
- Open its logs and check whether initialization completed or failed.
- Confirm that its health-check program exists in the selected image and that arguments refer to the configured username and database.
- Confirm that the named volume is mounted at the data directory expected by that image version.
- Check free storage, memory, permissions, and the pool connection.
- If reusing an initialized volume, retain the original initialization credentials and follow the database’s supported administration process.
A service_healthy dependency requires an explicit health check on the target service. A running process is not always a ready database. Do not remove the dependency just to make the next service start earlier.
Application cannot connect to its database
Use the database’s service name and private container port, such as database:3306 or postgres:5432. localhost inside the application container points back to that container. A pool IP or generated website domain is not a substitute for the private database hostname.
Both services must belong to the same stack on the same pool. Another stack, a standalone application, and your laptop cannot use that stack-private hostname. A dependency does not populate the application’s environment variables: set the expected host, database, username, password, or complete URL explicitly.
For URLs, encode username, password, and database components correctly. Template derived URL inputs perform that assembly privately. Never paste the full connection string into a support ticket.
Deployment is Failed
Earlier completed services and their data are retained. Inspect the failed service’s logs, correct its configuration or pool issue, and confirm the state of existing services. Once the operation is resolved, edit the existing stack, review the change, and redeploy deliberately.
A new operation can redeploy other declared services too. Take a backup when needed and plan for dependent clients and stateful downtime. There is no automatic transaction rollback that returns every service and database to their previous state.
Deployment is Unknown
Unknown means Infralane could not confirm preparation or submission. A callback may still reconcile a deployment already accepted by the pool.
- Keep the original stack and refresh its progress.
- Inspect the current service’s application and deployment history and the pool connection.
- If the final request is uncertain and its review remains on screen, use Check and retry reviewed deployment.
- If the state remains unknown, contact support with the stack and operation identifiers and redacted observations.
Do not submit a duplicate stack, delete the current stack, or assume an unknown outcome means nothing ran. New edits remain blocked while the operation is uncertain.
Copied stack has no data or missing inputs
This is expected: a copy creates separate applications and volume identities, and it never copies saved private inputs or database contents. Supply new inputs and use a deliberate, tested restore process if the new environment needs data. See Environments and copies.
Template became unavailable
Check the originating release and advisory. Availability is checked again when applying a new installation and before further service submissions; a release blocked during deployment can leave earlier services running. Retain their data and inspect the operation. See Template release availability.
Ask for help
Send info@infralane.cloud the stack name, environment, operation identifier, failed service, approximate time, and redacted error. Include the image tag or digest and relevant non-secret configuration. Exclude passwords, tokens, private inputs, database URLs, and unredacted logs or exports.