API hosting

Micro API hosting.

Not every API needs a platform built for scale. A webhook receiver that forwards a Stripe event to Slack, a single endpoint an internal tool polls, a redirect service, these are a handful of lines of code, and they deserve a handful of lines of hosting config. DenkOps gives a tiny API the same slot as a bigger one, just smaller, at the same flat price.

# a one-route webhook receiver
$ cat main.py
@app.post("/webhook") ...
 
deploy on DenkOps
→ live at https://my-webhook.denkops.app
slot: always-on · /persist mounted · egress: blocked by default

Even a one-endpoint service gets a durable /persist disk to log deliveries or dedupe webhook events, and an egress allowlist scoped to the one or two APIs it actually calls out to.

Start on DenkOps →

FAQ

Is DenkOps overkill for one tiny endpoint?

No, a single webhook receiver or internal utility endpoint is exactly one slot, the smallest unit DenkOps sells. It's part of the same €39/month, 5-slot starting plan as anything bigger, so a one-route API costs the same as any other slot rather than needing its own platform.

Can a micro API share infrastructure with my other services?

Each service gets its own slot, but they all live under the same DenkOps account, share the same egress allowlist model, and can be deployed and redeployed independently. A tiny webhook receiver and a bigger backend don't have to be on different platforms just because they're different sizes.

← API hosting · Flask webhook guide · Bun+Hono webhook guide