Deployments

A deployment builds a service, if it is built from a repository, and releases the result. Every deployment is kept. A service lists its own on its Deployments section, ten a page, and the Deployments page in the sidebar lists them across all the projects of the organization the console is in, newest first.

A deployment starts in one of three ways, and its Trigger says which:

Pressing Deploy opens the new deployment's page at once, where its log starts to stream.

A service runs one deployment at a time. While one is in progress, Deploy is greyed out, and its label says why: "A deployment of this service is already running", or "The service is suspended, so it cannot deploy".

Cloud can also refuse a deploy you press, with one of these sentences in a toast:

• "This account is suspended by Cahaves. Contact support to have the suspension lifted."

• For a paid service, "Add a card in billing to run apps past the free tier.", a sentence naming a month whose charge did not go through or whose invoice is past its due date, or "This would take this month to $27.40 against your $20 limit. Contact support to raise the limit." with the organization's own amounts, as Billing explains.

• "This service has unfinished backup work."

• "This service has an unconfirmed volume attachment."

• "This service is protected by unfinished restore work."

Deploy is greyed out or refused explains each one.

Each service numbers its deployments from 1 in the order they were asked for, so #12 is always the same release of the same service. The deployment's page shows:

• Commit: for a GitHub service, the short SHA and first line of the commit it built. Otherwise "Not built from a commit".

• Trigger, Started and Duration.

• The one sentence that says why it failed, when it failed.

• The pre-deploy database backup's status, when the service takes one.

• The Build log: the whole log so far, then each new line as it is written. It stays with the deployment after it finishes.

The page refreshes itself until the deployment finishes. For what the service writes once it runs, use its Logs section; Logs covers both.

On the Deployments page, Filter narrows the list to In progress, Successful, Failed or Cancelled, and Clear filter shows All statuses again.

Cloud marks an application's deployment Done only once a container of it is running. When the build finished but no container is running two minutes later, the deployment ends Failed with "The deployment finished, but nothing is running." A database's deployment is Done once the database is running, and ends Failed with "The database did not start within two minutes." when it is not. A compose stack's deployment follows the outcome the platform reports for it.

The first Done deployment of an application with no domain gives it an address on the platform's domain. Domains covers it.

The sentence on a failed deployment is written for you. It never carries a stack trace or anything that could hold a credential; the build log is where the detail is.

A deployment failed goes through each with its fix, and the sentences below cover a deployment in doubt.

Cancel, in the deployment's header, stops a deployment that has not finished.

• A Queued deployment ends Cancelled at once.

• A deployment that is Starting or Deploying is stopped on the platform. It keeps its status until the platform reports that it stopped, then reads Cancelled. If the platform refuses to stop it, the toast says so and the deployment runs on.

• A database's deployment has no build to stop. Cancel ends Cloud's wait for it, and if the database is already running the deployment still ends Done.

A deployment that has finished cannot be cancelled.

There is no rollback button, and a past deployment cannot be deployed again. To go back, deploy again from what you want to run. For a GitHub service, revert the commit and push, or point Branch on the Source card at another branch and press Deploy.

Cloud gives every deployment at most two hours from the moment it starts.

The engine has not confirmed this deployment's outcome. Cloud keeps checking for up to two hours, and the service stays locked until then.

The deployment did not finish within two hours, so Cloud stopped it.

The engine never confirmed this deployment's outcome, so Cloud stopped waiting after two hours. Check the service before deploying again.

Cahaves operators can end a deployment in doubt sooner, once they have checked the platform. One they end as failed reads "Cloud's operators checked the engine and ended this deployment."

A PostgreSQL, MySQL, MariaDB or MongoDB database can take a dump of itself before each of its own deployments. Set it on the database's Storage section, under Backup before deployment:

1. Have a dump schedule

   The dump uses one of the database's backup schedules for its database and destination, even while that schedule's timer is paused. With none, the form reads "Add a database backup schedule to enable this." Backups explains schedules.

2. Turn it on

   Set Before deployment to Back up this database, choose the Database backup schedule, and press Save deployment backup.

A deployment of that database then stays Queued until its dump is accounted for, and its page shows "Database backup pending", then "Database backup completed". When the dump is uncertain or fails, the page shows one of these:

A notification channel with the events Deployment succeeded or Deployment failed hears of every deployment that ends that way. Notifications sets that up.