Infrastructure for applications
Ship your code.We'll run it.
Connect a repository and Drumlin takes it from source to a running HTTPS service — builds, releases, databases, logs and metrics included. There is no cluster for you to operate.
- Built from
- main
- Instances
- 2
- Region
- DE1 · Germany 1
- Address
- api-7bvb32zq.apps.drumlin.cloud
How it works
From repository to running service.
Three steps, and none of them involve a cluster, a manifest or a load balancer.
01
Connect
Point Drumlin at a Git repository and choose a branch. Every deployment resolves that branch to an exact commit, so what runs is never ambiguous.
02
Deploy
Drumlin builds your application from its Dockerfile and turns the result into a release — an immutable image, pinned by digest, that can be redeployed or rolled back.
03
Run
Your service gets an address of its own and answers on it over HTTPS. Its logs, metrics, instance health and console are there from the moment it starts.
The product
Everything about a service, in one place.
State, resources, the release that is running and the logs it is writing — without opening a second tool.
CPU
340 m
Memory
412 MiB
Instances
2
Release
24
- Branch
- main
- Commit
- 7b21d9a
- Built in
- 18s
- Release
- 24
- Connected to
- api
- Backups
- continuous
Capabilities
What you get, without asking for it.
Deployments
Built from source.
Connect a repository and Drumlin handles the path from a commit to an immutable release running behind HTTPS.
- Builds from your Dockerfile, in an isolated sandbox
- Releases pinned by image digest, never by a moving tag
- Deployment history, with rollback to any previous release
- Scale a service up or down without redeploying it
Databases
PostgreSQL without operating PostgreSQL.
Create a managed database, grant a service access to it, and read the connection details from the dashboard or the CLI.
- PostgreSQL 17, with the processor, memory and disk you ask for
- Access granted per service, not shared by default
- Continuous backups to storage in a separate data centre
- Point-in-time recovery from those backups
Observability
Understand what your application is doing.
Logs and metrics belong to the service and are reachable from it — no separate account, no agent to install.
- Live and historical logs, searchable by service
- Processor and memory use, per instance
- Instance health and the state of every release
- An activity log of who changed what
Console
When you need to look inside.
Open a shell into a running instance from the dashboard or the CLI. Every session is recorded against the service, because a shell is the most invasive thing this platform can do.
- Authenticated, single-use sessions that expire
- Visible in the service's own activity log
- Available from
drumlin shell
From your terminal
The same platform, without the browser.
Deploy, roll back, scale, follow logs and open a shell without leaving the terminal. The command line talks to the same API as the dashboard and returns the same sentences when something goes wrong.
Underneath
Simple on the surface.
Serious underneath.
Drumlin is built on the same infrastructure a platform team would choose, and operates it so that you do not have to. None of this appears in the product — it is here because you should know what you are standing on.
Isolation
Your code doesn't run next to the platform.
Every workload is placed inside a sandboxed runtime on nodes reserved for customer code, and the boundary between tenants is enforced in the network and in the API rather than assumed. A service reaches its own environment and the internet; the control plane, the platform's own storage and every other tenant are simply not routable from it.
Builds get the same treatment. The steps in your Dockerfile are your code, running on our machines, and they are sandboxed as tightly as anything you deploy.
A service can reach
- Every other service in the same environment
- The databases it has been granted, on 5432
- The platform resolver, for DNS and nothing else
- The public internet
And cannot reach
- Any workload belonging to another customer
- The Drumlin control plane, its database and its storage
- The Kubernetes API and the node it happens to be on
- Instance metadata, and every private network range
Inbound, only the shared gateway and the service's own environment are permitted. Everything else is denied outright rather than left unmentioned.
Regions
Running in Germany.
One region today, operated by us rather than resold. More will appear here when they are real and not before.
DE1
Operational- Name
- Germany 1
- Location
- Germany, Europe
- Addresses
- *.apps.drumlin.cloud
Pricing
Simple usage-based pricing.
You pay for the resources your services reserve, metered per second. There is no cluster to pay for whether you use it or not, and no per-seat charge for looking at your own logs.
- Processor
- Per millicore-second reserved
- Memory
- Per MiB-second reserved
- Storage
- Per GiB-second provisioned
- Build time
- Per second of build
Rates are being finalised ahead of general availability. Every account can see exactly what it has used, and what it was charged for, in its own ledger from the first deployment.