Operate and update stacks

Open Stacks in the selected project. Search by stack name, environment, or starting template, or filter by environment. Open a stack to see deployment progress, service links, configuration controls, and any template origin.

Viewing requires project read access. Updating, copying, deleting configuration, and requesting database connection details require project write access. The backend checks access again when performing operations.

Read deployment progress

The ordered progress list identifies Waiting, Current service, and Deployed services. The stack page refreshes active progress periodically while visible; Refresh stack requests the latest state manually. You can navigate away while deployment continues.

Completed describes the deployment operation, not continuous health or an uptime guarantee. Open service logs and monitoring to investigate a later failure. The stack’s latest operation and an individual service’s latest release answer different questions.

Open individual services

In Services, select an application to view its deployments, logs, settings, storage, and scheduled jobs. Use these pages for operational investigation:

• Logs for startup and runtime messages.
• Deployment lifecycle for release outcomes.
• Monitoring for available resource and traffic history.
• Domains for generated and custom HTTP routing.
• Storage for persistent data and backups.

Treat the stack configuration as the configuration you intend to deploy together. A later stack deployment reapplies its declared configuration to the services; reconcile deliberate individual application changes with that stack before redeploying.

Use database connection details

Recognized database services expose Connection details. Open that page and deliberately reveal the connection to request its private hostname, port, database, and credential-bearing URI. Details hide again after one minute or when the tab is hidden. Select Copy connection URI only when needed, and only for a destination authorized to receive the credentials.

The hostname is the database service name, such as database or postgres. It resolves from services in the same stack on the same pool. It is not a public hostname or a connection address for your laptop or an application in another stack. Add a dependent application to the same stack when it needs this private connection.

Set the consumer’s connection variables as well as the deployment dependency. For an application expecting a single connection URL, store the whole URL as a private input. Do not paste passwords into a command, repository URL, support message, or configuration description.

Edit and redeploy

1. Wait for the current operation to finish and resolve any Unknown outcome. Editing is disabled during queued, preparing, deploying, or unknown operations.
2. Back up stateful services and read upstream upgrade instructions before changing images or storage paths.
3. Under Configuration, select Edit configuration.
4. Update services in Visual builder or Code. The stack name, environment, and pool remain fixed.
5. Leave a private input empty to keep its saved value. Enter a replacement only when it is safe to change.
6. Select Review deployment and inspect all service updates and creations.
7. Select Save and redeploy stack, then monitor each service.

A stack update creates a new saved revision and processes the services in the reviewed configuration. Do not assume only the field you edited or one service will be redeployed. Review the complete service list and plan for downtime where applicable.

Saved draft changes are not deployed until the final action. A review expires after 15 minutes. An intervening saved stack revision requires a fresh review.

Database initialization is not credential rotation

Database image variables such as POSTGRES_PASSWORD, MYSQL_PASSWORD, and MARIADB_PASSWORD initialize a fresh data directory. Changing them does not update an account already stored in a persistent database.

For recognized database services, Infralane rejects changes to protected initialization usernames, database names, and passwords that would disconnect dependents. Keep the saved values and rotate the real account using the database’s supported administration process, coordinating dependent clients and maintenance. The stack editor does not supply a database-account rotation workflow.

Changing image versions also does not perform a database migration. Follow the upstream upgrade procedure, take a recoverable backup, and test the process in a separate environment.

Export configuration

Select Export configuration to download <stack-name>.compose.json. JSON is valid YAML, and the file can be kept in version control or adapted in the Code editor.

The export includes the saved Compose configuration with named references replacing resolved environment values. It does not include saved input values, database contents, volume data, or a complete machine backup. Keep the appropriate private values separately in an authorized secrets system.

Repository URLs and non-secret references may still identify private infrastructure. Review the export before sharing it. Importing it elsewhere requires supplying inputs and arranging access again; it does not recreate the original stack identity or attach its old volumes automatically.

Template-based installations

Template origin shows the originating publisher, version, icon, and whether the configuration is original or customized. Expand Getting started for instructions captured with that release.

New registry releases never update installed stacks automatically. Follow the publisher’s operations and upgrade instructions and release-management guide. Editing advanced configuration retains the original provenance and can mark the installation customized; it does not turn it into a newly reviewed release.

Remove services and delete a stack

Removing a deployed service from YAML is rejected while its application exists. This prevents a stack edit from silently deleting production applications.

1. Review the service’s consumers, persistent volumes, and backup requirements.
2. Delete the service application explicitly through its application management workflow and confirmation.
3. Edit the stack configuration to remove that service and update dependencies or connection settings before the next stack deployment. Otherwise the declaration can create the application again.

To delete the stack configuration itself, delete all service applications explicitly and resolve any pending or unknown operation. Delete empty stack then becomes available. Its confirmation removes saved configuration, encrypted inputs, and stack deployment history; that cannot be undone.

There is no stack-wide automatic rollback or stop-all control in this workflow. Use supported application actions deliberately and account for dependent services and database compatibility. Never use deletion as a shortcut to resolve an uncertain deployment.