Skip to Content
We are conducting a survey to learn how startups, SMEs, developers, and technical teams currently host, deploy, and operate software. Take the survey
Infralane
Infralane
DeploymentsDeployment lifecycle

Deployment lifecycle

Every application release creates a deployment entry. Use deployment history to distinguish a configuration change from the release produced by that change.

View deployment history

Open the application, then select Deployments. Each row shows an identifier when available, creation and update times, and the current state. Select a row for details and progress output.

Statuses

StatusMeaningWhat to do
Pending / In progressThe release is still being prepared or startedKeep the page open or return later and refresh
LiveThe release completed and is serving according to the platform stateTest the application and review logs
FailedThe release did not completeRead the final meaningful error and correct its cause
InactiveThe deployment is no longer the active releaseUse it for history; verify the current live deployment

Follow progress

The deployment details page shows the current state, timestamps, a run identifier when available, and progress output while the deployment is active. Output can pause temporarily even while work continues; use Refresh to update the recorded state.

Do not post deployment output publicly without reviewing it. Well-behaved applications should not log secrets, but logs can still contain customer data, internal paths, or sensitive request details.

After a live deployment

Complete a small release check:

  1. confirm this is the intended application and source version;
  2. open the public endpoint when present;
  3. test health and one important user path;
  4. check runtime logs for errors or repeated restarts;
  5. confirm dependent services behave normally;
  6. record the change according to your team’s release process.

Configuration saves and deployments

Saving any application settings section starts a new deployment. Make one coherent section change, save it, and verify that release before editing another section. This keeps the cause of a failure easier to identify.

Last updated on