Container Apps and Apps in App Deployment
Your Container Apps servers and your apps are App Deployment deployments already. See what changed, what stayed the same and what is new for each.
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, until you move it to usage billing.
Where to find them
Section titled Where to find themIn the dashboard, open App Deployment. It lists your servers and your apps together, one card for each deployment. The kind buttons, which start at All, show one kind at a time, such as Servers, Databases or Web services, 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 words
Section titled The words| Before | In App Deployment |
|---|---|
| Container Apps | App Deployment |
| A server | A deployment of a game server or a database. The server is its instance in the location you chose. |
| An app | A web service: a deployment built from git or from a container image |
A deployment of an app, in the Apps API |
A release |
| A replica | An instance |
| A region | A location |
The glossary defines each of them.
A server you ordered from Container Apps
Section titled A server you ordered from Container Apps- 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). You can move it to usage billing, which bills it by what it uses (Switch a service to usage 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).
- Spend limits and the free amounts of use apply to deployments billed by use. A server billed by its own plan is billed only by that plan.
An app you made with Apps
Section titled An app you made with Apps- Its releases, domains and build settings stay, and each push builds a release as before.
- Its variables are now in the
allenvironment, 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. Once billing is turned on for it, it is billed like any web service, by what its instances use, and its instance size becomes its starting memory limit (How App Deployment is billed). An account billed by invoice has it on its monthly invoice.
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).
Scripts and the API
Section titled Scripts and the API/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.