A slot is the unit DenkOps sells: one always-on worker with its own CPU, RAM, and durable disk, EU-hosted. Deploy a project into a slot, and everything that happens inside it, requests, redeploys, background jobs, is unlimited. You are not paying per call, per invocation, or per gigabyte-second. You are paying to keep one thing running, and then using it as much as you want.
What actually lives in a slot?
One project, running continuously. Because the worker is already warm, there is no cold start: the first request after a quiet hour behaves exactly like the thousandth request in a busy minute. Deploys inside the slot are unlimited too, so pushing a fix does not cost anything beyond the deploy itself, and a managed cron job or a background task can run in the same slot without a separate metering line. The disk is durable, so state written to /persist survives restarts and redeploys, it is the same slot, not a fresh container each time.
Why does per-request billing get unpredictable?
Because the bill depends on traffic you do not fully control, and that gets worse, not better, as you add clients. One connector with a bursty client, an agent that retries aggressively, a cron job that fires more often than planned, and the invocation count for that month is a surprise. Multiply that by twenty client connectors and you are reading twenty line items to find out which one moved. Flat per-slot pricing removes the variable entirely: a slot costs the same whether it serves ten requests today or ten thousand.
The pricing
Slots are flat and slot-based. Five slots for €39 a month; every slot beyond that is €5 a month. As a formula:
cost = 39 + max(0, N - 5) * 5Where N is the number of slots you are running. A few points on that curve:
| Client connectors (N) | Monthly cost | |---|---| | 5 | €39 | | 10 | €64 | | 50 | €264 | | 100 | €514 |
Ten client connectors is €64 a month, fixed, known in advance, the same whether client three sends five requests or five thousand this month. Fifty clients is €264. A hundred is €514. No invocation counter to watch, no month where a client's traffic spike shows up as a bill you did not expect.
Why this matters more, not less, as you scale clients
Per-invocation pricing is fine for a single app with roughly steady traffic; you can estimate the bill because there is one number to estimate. Running one slot per client, the pattern in one template, many clients, replaces that with N independent traffic patterns you would otherwise have to sum every month. Flat per-slot pricing turns that sum into arithmetic you can do in your head: count your active clients, apply the formula, done. See the full breakdown and try the slider on pricing.