App Deployment

App Deployment runs what you deploy for you, behind our edge: a game server or a database from the catalogue, a web service built from a git repository or run from a container image, or a static site. Each one is a deployment. It runs in the locations you choose, one instance in each unless you set more, and the edge sends each visitor to the closest location that is serving. Container Apps servers and Apps apps are deployments now, and keep their addresses and their APIs (Container Apps and Apps in App Deployment).

If you need a whole virtual machine with root access instead, use Cloud Compute.

A game server or a database

Software from the catalogue, such as a Minecraft world, MariaDB, PostgreSQL, MongoDB or Redis. We install it and give it an address, and you run it with a console, a file manager, SFTP, snapshots, schedules and shared access. It keeps its files and data on its server. The list calls it a Server or a Database.

A web service

Your code, built from a git repository at each push, or a container image you built yourself, such as a Node.js, Python, Go or PHP app. It runs as instances of its live release, which can scale between a minimum and a maximum as traffic changes and sleep when nobody uses them. The list calls it a Web service.

A static site or a hybrid site

A site built to plain files, such as HTML, CSS and JavaScript, which the edge serves from every location with no instance. A hybrid site adds server routes that run on instances. The list calls them a Static site and a Hybrid site.

• Each build of a web service, a static site or a hybrid site is a release. The release that serves production is the live release. You start a release with Deploy a branch…, Rebuild… or Redeploy…, and you can promote a preview or roll back to an earlier release (Releases).
• A push to another branch, or a pull request, can build a preview: a release at an address of its own, which never replaces production (Deploy from a git repository).
• A running copy of a release in one location is an instance. A game server or a database runs one server in each location it was ordered in (Choose locations and scaling).
• Every deployment gets an address under the platform's domain, and you can add your own domains (Add a domain and protection).
• A web service or a hybrid site is billed by what its instances use, and a static site costs nothing to run. Every account gets some use free each month (How App Deployment is billed). A game server or a database is billed by use too, with a size (How game servers and databases are billed).

The glossary defines each word.

The App Deployment page in the dashboard lists every deployment you own, the servers someone has shared with you, and the deployments of every organization you are a member of. Under the heading, a line says how many there are ("18 in total"), or how many match your filters ("4 of 18"). Select New deployment to order one for your account (Order a deployment). To order for an organization where you are an owner or admin, select For an organization and the organization. The menu is left out when you are not an owner or admin of any organization.

A new account has no deployments yet, and the page says No deployments yet with one card each for a game server or a database, a web service, a static site and a container image. Each card opens the order page for that kind, with the organization chosen when you opened the list from its tab.

Four tiles sit above the list. Each one except Usage this month is also a filter on the list. Select Running or Needs attention to show those deployments, and select it again to turn the filter off.

• Deployments counts every deployment. Selecting it clears every filter and the search, and it is highlighted only while none is on.
• Running counts the deployments that are live or running, and filters the list to them. A deployment that needs attention is not counted here.
• Needs attention counts the deployments that fail their health checks, did not finish installing, are suspended, or are paused at their spend limit.
• Usage this month shows what use billed by the second has cost so far. It appears only when you may read the account's billing, and it does not filter.

When something needs attention, a strip under the tiles says "3 deployments need attention". It is for the full list, so it is hidden while any filter or the search is on. It lists up to three deployments, or one on a phone, each with the reason and a button that goes to the fix: See instances for a web service that fails its health checks, Open server for a server that did not finish installing, See why for a suspended deployment, and Review the limit for one paused at its spend limit. Select Show all to filter the list to every one of them. A suspended deployment reads "This deployment is suspended."

The toolbar narrows and orders the list:

• Kind buttons (All, Servers, Databases, Web services, Static sites and Hybrid sites), each with a count. They appear when the list holds more than one kind.
• Cards and Table switch how the list looks. Your choice is kept in your browser. A phone always shows cards.
• The search box, "Search name, address or software", finds a deployment by its name, address, software, repository, image or organization.
• The Status menu holds All statuses, Live or running, Starting, Not running and Needs attention, each with a count, and leaves out a status that no deployment has. A deployment is under one status only, and Needs attention comes first: a suspended deployment, or one that a spend limit paused, is under Needs attention and not under Not running, so the counts add up to the number of deployments. Its badge still reads Suspended or Paused. A link that asks for the status suspended opens Needs attention.
• The Location menu picks one location. A deployment that runs in every location matches each one.
• The Owner menu picks Your account or one organization. It appears when an organization's deployment is in the list.
• The Sort menu holds Newest first, Name, A to Z, Problems first, Latest release and Highest cost. In the table, selecting a column heading sorts by it too.
• The Group by menu holds No grouping, Kind, Owner (when organizations are listed) and Status. It works in the cards view only.
• Clear filters appears while any filter is on, and removes the kind, status, location, owner and search. It keeps the sort and the grouping.

The address holds the filters, the sort and the grouping, so a link to the page keeps them and a reload brings them back. The list shows 24 deployments a page. When there are more, page buttons and the range, such as "1–24 of 35", appear below it.

Each card shows:

• The kind icon, the name, which opens the deployment, the kind with the organization's name when it belongs to one, and a status badge.
• The address with a button that copies it. For a web service or a site it is the web address. For a game server it is the IP address and port, or the join address when the server has one, as your servers list shows it; a database shows the same address. The kind line then names the software, for example "Server · Paper 1.21.1". A server of an organization that is not in your own servers list shows no address.
• A red line for a problem, such as "Its instance is failing its health checks.", or an amber line for a deployment paused at its spend limit, each with the link to the fix (See why for a suspended deployment, Review the limit for a paused one).
• Where it runs, Instances with a small bar of how many are healthy, starting, failing and stopped (Files for a static site), Memory (Size for a game server or a database) and, when its cost is known, This month for use billed by the second or Plan for a deployment billed by a monthly plan, which shows the plan's price for its billing cycle.
• For a web service or a site, its latest release: the title, the commit and when it was made.

The footer of a card has the buttons you use most:

• A stopped server that runs in one location shows Start. A running one shows Restart and Stop, and each asks you to confirm. The question reads "Stop" or "Restart" and then the deployment's name, and its button reads Stop server or Restart server for a game server, and Stop database or Restart database for a database. While a server is starting, its card says "Getting ready. This page updates itself."
• A web service with a live release shows Open site, which opens its address. One with no live release shows See releases. A web service that is paused or suspended shows neither, and its problem line carries the link.
• A deployment in several locations has no power buttons here, because its Instances tab has them. A deployment that is paused or suspended has none either, and neither does an organization's server when your role in the organization is below admin.

The ... menu, named "More actions for" and the deployment's name, opens the deployment's tab: Console, Files, Backups, Instances (for a server in several locations), Billing and Settings for a game server or a database, and Releases, Logs, Metrics, Domains, Variables and Settings for a web service or a site. A static site has no Logs. Copy address copies the address shown on the card, including a server's IP address and port, and Redeploy… runs the live release of a web service or a hybrid site again, after you confirm it. Redeploy… appears only for someone who may change the deployment (Deploy, promote and roll back releases).

The Table view shows the same figures in the columns Deployment, Status, Owner, Locations, Instances, Latest release and This month, which holds a plan's price when there is no use to bill. Owner appears when an organization's deployment is in the list. Each row ends with an icon button that opens its address in a new tab, and the same ... menu. A narrow window leaves out some columns. While a server is starting, the page reads the list again every eight seconds, so its badge changes without a reload.

An organization's deployment opens on the same page as your own, with the organization's name on the line under its name. Owners and admins of the organization change it there; every other member reads it without the controls (Run apps for an organization). The organization's own App Deployment tab lists the same deployments. While you work in another account from its team, the list holds that account's deployments only.

Select a deployment to open it. Its tabs follow its kind. A game server or a database has Overview, Console, Files, Databases, Backups, Billing, Settings and More. More lists its other sections: Instances, Snapshots, Schedules, Ports, Users, Software, Import, Rules, Updates and Resources. Each section keeps its own address, such as /dashboard/deployments/<uuid>/snapshots, and More stays selected while one is open. Resources shows the CPU, memory and disk the server uses and the slots its plan gives. A web service has Overview, Releases, Instances, Domains, Variables, Networking, Logs, Metrics, Git, Usage, Billing and Settings. A static site has no Instances or Logs tab.

The Settings tab renames a deployment and holds how it builds and runs: Framework, Install command, Build command, Start command and Output directory, then Port and Health check path, or the Image of one that runs an image. Select Save changes. A change reaches the running instances with the next release, which Redeploy… starts, and a change to how it builds with the next build, which Rebuild… starts (Deploy, promote and roll back releases). A game server's or a database's own settings are on its server's tabs (Server settings).

To delete a deployment, select Delete deployment… on the same tab and type its name to confirm. For a game server or a database, leave Save a snapshot of its data first ticked to keep its files in Snapshots, where a new deployment can start from them. You cannot undo a deletion: a web service or a site stops answering at every address, and its releases, domains and variables go with it. A deployment that already ends on a date is deleted then.

The public App Deployment page describes the product, with its prices from the catalogue. The public Game servers page lists the games and software we host, and says how a server sleeps when it is empty and how players join it. Order from the dashboard, which shows the plans, software and locations that are actually available.

Get started:

• Order a deployment
• Host a Minecraft server, from order to first join
• Deploy from a git repository, with previews of branches and pull requests
• Host a static site or a hybrid site
• Use the Coritan CLI to deploy from your computer or from CI

Run a web service or a site:

• Environments and variables, and the variables Coritan services give a deployment
• Choose locations and scaling: where it runs, how many instances, and sleeping when idle
• Deploy, promote and roll back releases, and send part of the traffic to a new release
• Add a domain and protection
• Logs and metrics, with log drains and alerts

Run a game server or a database:

• Use the console and power controls
• Server settings: name, address, join address, startup variables and tags
• Change the server software, with plugins, mods and modpacks, installed addons, Java settings, a resource pack, safe mode, Bedrock crossplay, cross-version play and Bedrock packs
• Manage server ports
• Manage server files and connect with SFTP
• Import a server from another host
• Create and manage server databases
• Take a server snapshot, then manage and restore snapshots for your whole account
• Manage server backups made before snapshots replaced them
• Schedule server tasks
• Install server updates and create server rules
• Share a server with other users

Billing:

• How App Deployment is billed: what a web service or a static site pays for, what each month includes, and spend limits
• How game servers and databases are billed: memory, disk, CPU and data out for a server, with an example
• Manage a server's billing: add-ons, cancelling and the older plan prices, for a server
• Switch a service to usage billing: move a deployment or a server that keeps a plan price

Reference:

• Container Apps and Apps in App Deployment: where everything moved
• Server limits and rate limits
• Troubleshoot servers
• How free servers work, for an organization that sells a free plan on its own storefront

• The plan you order sets each instance's memory, CPU and disk, and for a game server or a database its database, backup and port slots. The Size and add-ons card on a server's Billing tab shows them.
• Your account plan sets how long logs are kept. On older terms it also sets how many locations one deployment can run in, how many builds run at once, and whether it has previews, protection, autoscaling and log drains. A deployment billed by use has those open (What your plan includes). Every account gets the same free amounts of use each month (Usage rates).
• A game server or a database can take extra port and database slots as add-ons, which renew with it (Add capacity to a service).
• Snapshots draw on one allowance for your whole account. How snapshot storage works explains how big it is.
• Some actions, such as power signals, are rate limited per server. Server limits and rate limits lists them.

GET /api/v1/client/deployments lists your deployments of every kind, newest first. Filter it with kind (template, git, image, static or hybrid), status (active, paused or suspended), location, and q for part of a name or a domain. Each one carries its uuid, name, kind, status, url, placement, instances and billing, and a game server or a database lists its servers under template.servers, with the uuid the server routes below take. counts and kinds count the list by status and by kind. GET /api/v1/client/deployments/{uuid} returns one deployment with its instances, its domains and its five newest releases. An organization's own deployments are under /api/v1/orgs/{org_slug}/deployments, for its members.

curl "https://api.coritan.com/api/v1/client/deployments?kind=git" \
  -H "Authorization: Bearer $CORITAN_TOKEN"

PATCH /api/v1/client/deployments/{uuid} changes only the fields it names: name for every kind, build (preset, install_command, build_command, start_command and output_dir; a dockerfile_path answers 422 with dockerfile_unsupported) and runtime (port and health_check_path) for the kinds that build or run, and image.ref for one that runs an image. redeploy_required and rebuild_required in the answer say whether the change waits for a new release or a new build. A game server's or a database's other settings change under the server routes, and placement, git, processes and scaling have routes of their own.

DELETE /api/v1/client/deployments/{uuid}?confirm=<name> deletes a deployment, with its name, or its slug, in confirm. For a game server or a database, keep_snapshot (true when left out) saves its data first. A deployment a service pays for cancels that service at once, and a deployment already ending answers 409 with already_ending. The same two routes answer under /api/v1/orgs/{org_slug}/deployments for an organization's owners and admins.

The server routes keep answering for a game server or a database. GET /api/v1/client/servers lists the servers you own or share. Add ?tag= with one of your tags to list only the servers that carry it. For a server someone shared with you, owner_email is null.

curl https://api.coritan.com/api/v1/client/servers \
  -H "Authorization: Bearer $CORITAN_TOKEN"

Each item carries the server's uuid, name, status, ip_address and port, its plan limits (memory_mb, disk_mb, cpu_percent, allocation_limit, database_limit, backup_limit), template_name for its software, location_name, service_id and tags. Use the uuid in every other server request.

GET /api/v1/client/servers/live returns the power state and current usage of several servers in one request. Pass up to 50 server UUIDs, separated by commas, in the uuids parameter; without it you get your 50 newest servers.

curl "https://api.coritan.com/api/v1/client/servers/live?uuids=$SERVER_A,$SERVER_B" \
  -H "Authorization: Bearer $CORITAN_TOKEN"

The response holds items, one per server with its uuid, state and usage, and degraded, which is true when at least one server's state is unknown because it could not be read in time.

GET /api/v1/client/servers/{uuid} returns one server with the same fields, plus variables (its startup variables) and startup_command. A server you cannot see answers 404 with Server not found. A server that is being deleted answers 409 with the reason server_deleting.