How it works

A repository goes in.A running service comes out.

This page is the whole thing end to end: what happens, in what order, and who is responsible for each part. It is longer than the front page on purpose: the front page is for deciding whether to look, and this is for looking.

1

You connect a repository

You install the Drumlin GitHub app on the accounts or repositories you choose. It is the same app for every customer, and it can see only what you pick, and installing it on one repository does not show us the others.

What Drumlin needs from a repository is a Dockerfile. There is no file of ours to add and no branch to name after us. If your project builds in Docker today, it deploys here today.

A repository often holds more than one deployable thing, a frontend and the API behind it. Each becomes its own service, pointed at its own directory and its own Dockerfile.

2

A branch is resolved to a commit

You deploy a branch; Drumlin writes down the exact commit it was pointing at. Every build records the commit it was given, so the answer to "what is in production" is a hash you can check out.

3

The image is built, away from everything else

The build runs on machines set aside for building, not on the ones running your application, so a build that eats a node cannot take a running service down with it. It has no access to the platform, no access to other tenants, and only the credentials needed to fetch your code.

The output is pushed to the platform's own registry and pinned by digest. A tag can be moved to point at different code; a digest cannot.

4

A release is created

A release is the immutable pairing of an image digest, the commit that produced it, and the build that did the producing. A service runs exactly one release at a time. Going back deploys the earlier image again and never rebuilds it. The old image still exists, so a rollback takes seconds and cannot fail differently than the first time it ran.

5

The service starts inside a sandbox

Your container runs behind its own kernel boundary and never shares the machine's. It may run as root inside itself, which is its own business, and it can do the ordinary things an image needs at start-up: listen on a low port, change ownership of its own files, drop to its own user.

What it cannot do is reach the machine underneath: mount a filesystem, create a device, open a raw socket, trace another process. An image that expects to own a machine will be refused here.

6

It gets a name and a certificate

Every service is reachable immediately at a generated address. Point your own domain at the region and prove you own it, and the certificate is obtained and renewed without you doing anything again.

Inside an environment, services reach each other by name on port 80, whatever port the application itself listens on. Only services in the same environment can reach each other. Production cannot talk to staging, and no other customer can reach either. That boundary is in the network, not in configuration.

7

When it breaks, it says why

The logs are there, live and historical, with the processor and memory of every instance. But a log is evidence, not an explanation, so the platform reads its own evidence: an upstream that does not exist, a port nothing is listening on, an image compiled for the wrong processor, a server bound to loopback. Each of those becomes a sentence saying what happened and what to change.

When reading is not enough, open a shell inside a running instance. That session is authenticated, single-use, expires, and appears in the service's own activity log. A shell is the most invasive thing this platform can do, so it is visible where somebody would look for it.

8

It is metered while it runs

At the top of every hour Drumlin looks at what your account is holding: the processor and memory of everything that is running, and the disk of every database and volume. It prices that and writes the reading down. Nothing is charged at that moment; the reading is evidence.

At the start of each month those readings become one invoice for the month that ended, with a line per resource and the quantity beside it. Compute is counted only while a service is running. Stop one at 14:05 and the reading taken at 15:00 leaves it out. Disk is counted either way, because a disk holds its bytes whether or not anything is reading them.

You can watch the month happen: the billing screen shows what it has cost so far, exactly, alongside an estimate of where it will end up, and the hourly readings behind both. Any figure on an invoice can be traced to the hours that produced it, which is the whole reason they are kept. The rates are on the front page.

Boundaries

What is ours and what is yours.

Drumlin is responsible for

  • The machines, the network between them and the sandbox around your code
  • Building your image and keeping every release it produced
  • Restarting your service when its process exits
  • Certificates, and renewing them before they expire
  • Backing up managed databases and rehearsing the restore
  • Copying your volumes off this machine, and letting you put one back yourself
  • Keeping other tenants out of your environment

You are responsible for

  • What your application does, and what it stores
  • Its Dockerfile building, and its process staying up
  • Choosing a volume or a managed database for what you store, because a container's own filesystem keeps nothing past a restart
  • Which port it listens on, and telling us
  • Being lawful about the personal data it processes

Still reading?Then you may as well try it.