# App Deployment and Cloud Compute compared

> Which way to run software on Coritan suits a game server, a database, a web service from git, a static site or a whole machine of your own.

Source: https://www.coritan.com/docs/learn/choose-a-compute-product/

In the dashboard:

- /servers: https://www.coritan.com/servers

Coritan runs software for you on two products, which differ in how much you control and how much Coritan does for you:

- *App Deployment* runs a game server or a database from our catalogue, a web service from a git repository or a container image, or a static site, in one location or in several. Coritan installs or builds it and keeps it running. Container Apps and Apps are part of it now, as [Container Apps and Apps in App Deployment](/docs/managed-containers/moving-to-app-deployment/) explains.
- *Cloud Compute* gives you a whole virtual machine with root access. You install and run everything on it yourself.

On Cloud Compute an *instance* is a virtual machine. On App Deployment an instance is one running copy of a deployment in one location. [Cloud servers](/docs/learn/cloud-servers/) explains the other words on this page.

## Side by side

| | App Deployment: a server from the catalogue | App Deployment: a web service or a site | Cloud Compute |
| --- | --- | --- | --- |
| What you get | A *deployment* that runs the software you chose on a server | A *deployment* whose *releases* run as instances, or as files the edge serves | An instance: a virtual machine |
| Software | From the **Catalogue** on the order page | Built from your git repository, or your own container image | Anything, on the operating system image you chose |
| How you run it | Console, file manager, SFTP and schedules in the dashboard | Releases, previews and environment variables, in the dashboard or with the CLI | SSH and a console, with root access |
| Address | A port on the machine's shared address, a join address or a floating IP | An address on our edge and your own domains, over HTTPS | A public IPv4 address of its own |
| Files on its disk | Kept, and saved with snapshots | Not kept from one release to the next | Kept, and saved with snapshots and backups |
| Where it runs | One location, or several with a server and its own data in each | One location or several, with one instance in each unless you set more | One location |
| How it is billed | In one location, its plan, paid for each billing cycle or by the hour. In several, as a web service is | Pay as you go or monthly per location, with your plan's allowances. A static site is one of your plan's websites | A plan, paid for each billing cycle or by the hour |

[How App Deployment is billed](/docs/managed-containers/how-billing-works/) explains the two ways to pay and what the allowances cover.

## Choose App Deployment

- For a game server such as Minecraft, with a console, a file manager and plugins, and no machine to look after.
- For a database such as MariaDB, PostgreSQL, MongoDB or Redis, which we install for you.
- For a website or an API that you keep in git or build into a container image, when you want each push to make a release and a way to roll back to an earlier one.
- For a static site, whose build makes only files. The edge serves them, so no server runs for it.
- When you want copies in more than one location, near the people who use them.

A server's **Databases** tab also creates MariaDB databases for the plugins the server runs, on a shared host in its region ([Create and manage server databases](/docs/managed-containers/databases/)). A web service keeps nothing on its disk from one release to the next, so keep its data in a database or in [Object Storage](/docs/object-storage/).

## Choose Cloud Compute

- When you need root access, an operating system of your choice, or software that neither the catalogue nor a container image of your own can run.
- To run several programs on one machine and set it up your own way.
- When you are comfortable with a command line and with keeping the system up to date.

## Using them together

A web service can keep its data in a database you deployed from the catalogue. A *binding*, which you make with the API, connects the two and puts the database's address and login in the web service's variables ([Environments and variables](/docs/managed-containers/environments-and-variables/#bindings)). A game server, a database or an instance can sit behind a web proxy on your own domain, which serves it over HTTPS ([Web proxies, origins and the WAF](/docs/learn/web-proxies/)). A web service or a site is behind our edge already.

## Next steps

- [Run an app or a database](/docs/get-started/run-an-app-or-a-database/)
- [Get a cloud server](/docs/get-started/get-a-cloud-server/)
- [Order a deployment](/docs/managed-containers/order-a-server/)
- [Deploy from a git repository](/docs/managed-containers/deploy-from-git/)