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.
In the dashboard
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 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 explains the other words on this page.
Side by side
Section titled 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 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 | By what it uses: memory while it runs, disk while it exists, CPU and data out, with Server access | By what it uses: memory, CPU, requests, data out, builds and logs, with free amounts every month. A static site costs nothing to run | By what it uses: memory while it runs, disk while it exists, CPU and data out, with Server access |
How usage billing works explains what each product pays for and what each month includes, and every product has a worked example: servers and databases, web services and sites and Cloud Compute.
Choose App Deployment
Section titled 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). 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.
Choose Cloud Compute
Section titled 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
Section titled Using them togetherA 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). 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). A web service or a site is behind our edge already.