Coming from a VM
Šis turinys dar neišverstas į lietuvių kalbą.
If your current setup is a virtual machine per customer — provision, install, configure, repeat — this page is the translation. Nothing here assumes you have used containers before.
What you do today
Section titled “What you do today”The usual shape of it:
- Provision a VM for the new client.
- Install the runtime, a database, a cache, a web server.
- Copy the app onto the box and wire up a service to keep it running.
- Configure the reverse proxy and get a certificate.
- Set up backups. Maybe. Set up log rotation. Maybe.
- Open the right firewall ports by hand.
- Next month, do all of it again for the next client.
It works. The problem is not that it is wrong — it is that step 7 never stops, and that nothing on that machine can tell you what this one client actually costs you.
What stays exactly the same
Section titled “What stays exactly the same”Worth saying plainly, because this is the part people expect to lose:
- The same Linux. Same distribution, same packages, same versions if you want them.
- The same application. No rewrite, no framework change, no code changes to “become cloud native”.
- The same install steps.
apt install,npm ci,pip install— all still there.
What changes
Section titled “What changes”One thing: where the install steps live. Today they are in a runbook, a shell script,
or somebody’s memory. On Debesis they go in a Dockerfile — a text file that lists the
same commands, in order, so the machine can rebuild the environment instead of a person.
Everything else on this page is a consequence of that.
The mapping
Section titled “The mapping”| On your VM today | On Debesis |
|---|---|
| The VM itself | A Compute service running your image |
apt install steps in a runbook |
The same lines in a Dockerfile |
A systemd unit to start the app |
The container’s command and arguments |
| nginx in front, plus a certificate | Expose the service externally; TLS is handled |
.env on the box |
Environment variables, and Secrets for the sensitive ones |
| PostgreSQL installed on the box | A managed SQL service |
| Redis installed on the box | A managed Cache service |
| A data directory on local disk | A Storage volume, with snapshots |
Log files plus logrotate |
Logs, collected for you |
scp the build to the server |
Push an image to the Container Registry |
| One VM per app | One project per app |
| “How much does this client cost?” — no answer | A per-project line on the bill |
The part that is actually new
Section titled “The part that is actually new”You have to write a Dockerfile once per application. Not per deployment — per application.
If you run the same product thirty times over, that is one file, and each deployment is a
project pointing at the same image with different configuration.
It is usually shorter than the runbook it replaces. If you would rather not start from a blank file, Ask Debesis will work through it with you, and the founders will build the first one with you directly — mail founders@debesis.dev.
Common objections, answered
Section titled “Common objections, answered”“I need root on the box.” Inside your container you are root. What you do not get is a pet machine that drifts from every other machine — which is the thing that makes the thirtieth client expensive.
“My app writes to the local filesystem.” Attach a Storage volume and mount it. The app does not need to know the difference.
“I need to SSH in and look around.” You need the outcome of that: logs, metrics, a shell to debug with. Logs and metrics are collected per service.
“What about scheduled jobs?”