Container Apps and Apps in App Deployment

Container Apps and Apps are now one product, App Deployment. There is nothing to move: each server you ordered from Container Apps and each app you made with Apps is already a deployment, with its data and its addresses. A server also keeps its price.

In the dashboard, open App Deployment. It lists your servers and your apps together, one row for each deployment. The kind filter, which starts at All kinds, shows one kind at a time, such as Server, Database or Web service, the kind an app is now. A link you saved to a server's or an app's page opens its deployment's page.

A server's tabs, such as Console, Files and Backups, are on its deployment's page (Use the console and power controls).

The glossary defines each of them.

• Everything on it stays as it was: its files, console, backups, databases, schedules, ports and join addresses.
• Its plan, price, billing cycle, invoices and renewals do not change. You change its plan on its Billing tab, as before (Manage a server's billing).
• It keeps running in the location you ordered it in. To run the same server somewhere else, take a snapshot and start a new deployment from it there (Start from a snapshot).
• Pay as you go, allowances and spend limits apply to deployments ordered with them. A server billed by its own plan is billed only by that plan.

• Its releases, domains and build settings stay, and each push builds a release as before.
• Its variables are now in the all environment, so every release still reads them. You can give production, previews and development their own values (Environments and variables).
• Apps did not bill it. Its Billing tab says how it is billed now, and once it has a billing mode it is billed as any deployment is: by the hour at its instance size's price, from the next whole hour, or monthly for the instances you commit to (How App Deployment is billed). Pay as you go is paid from prepaid credit, so an account billed by invoice puts it on Monthly per location there.

What it can do now:

• Build a preview of each branch, through the GitHub App (Deploy from a git repository).
• Run in several locations, scale with traffic, sleep when idle, and run workers and scheduled jobs beside its web process (Choose locations and scaling).
• Ask visitors for a password or a Coritan sign-in, and filter and cache its traffic at the edge (Add a domain and protection).
• Send part of the traffic to a new release first (Send part of the traffic to a new release).
• Keep its logs, send them to your own service, and show its metrics (Logs and metrics).
• Deploy from a terminal or from CI (Use the Coritan CLI).

/api/v1/client/servers and /api/v1/client/apps keep answering as they did, so a script written for Container Apps or Apps keeps working. The Apps API still documents the app routes. What is new is on /api/v1/client/deployments, and on /api/v1/orgs/{org_slug}/deployments for an organization's servers and apps.

A deployment has an ID of its own. For an app, it is the app's ID. For a server, it is new: the deployment lists the server's own ID as server_uuid in its instances, and the server's routes still take that ID.