Simplifyd has a static site service type that skips the whole detour. You create the service, publish your built assets, and they are served from object storage behind our edge.

Create the service

From the console, create a service and choose Static site. There is no image to pick and no port to expose, because nothing is running — the bucket is the service.

Publish your files

Files are published inline through the API, so anything that can make an HTTP request can deploy. The CLI wraps it:

npm run build
simplifyd static publish ./dist

That last command replaces the previous contents in place. There is no build step on our side to wait for and no window where half the old site is serving next to half the new one.

Or let an agent do it

Because publishing is a plain API call rather than a Docker build, an AI agent connected over MCP can deploy for you. Point Claude at your repo, connect the Simplifyd MCP server, and "build this and publish it" is a single instruction — no local Docker daemon, no registry login, no CI runner.

This was the actual reason we built inline publishing the way we did. An agent cannot run a Docker build inside a chat session, but it can absolutely send files to an endpoint.

Attach your domain

Custom domains attach as bucket aliases and certificates are issued automatically. Point a CNAME at the address we give you and the certificate follows.

A static site should cost you one command and one DNS record. Everything past that is accidental complexity someone else decided you needed.

If you have been putting off moving a marketing site or a docs build because the container work was not worth it, this is the path that removes the excuse.

The interesting part is what happens when someone provisions the smallest possible cluster.

Why a one-broker cluster hangs

Kafka creates internal topics for its own bookkeeping, the best known being __consumer_offsets. By default those topics ask for a replication factor of 3. On a healthy production cluster that is exactly what you want.

On a single-broker development cluster it is unsatisfiable. Kafka cannot place three replicas on one broker, so the topic is never created, so the cluster never reports ready. Nothing in the logs says "your replication factor is impossible" — it simply waits.

Anyone who has stood up a scratch Kafka to test a consumer has hit this and assumed the operator was broken.

What we do instead

We clamp internal topic replication to the actual broker count at provision time. A one-broker cluster gets a replication factor of one and comes up in under a minute. A three-broker cluster gets three. You do not configure it and you cannot get it wrong.

Two topologies

• Standalone puts the broker and controller roles on a single node. It is for development, and we are direct about that — one node is one failure domain.
• Cluster splits brokers and controllers into separate node pools that scale independently, which is what you want when the thing on the other end is a payment stream.

Storage scales with brokers. Controllers hold metadata, not your messages, so they take a fixed small volume rather than whatever you sized your brokers for — you are not billed for broker-sized disks on nodes that will never fill them.

What we did not ship

There is no public endpoint. Kafka clients reconnect to whatever address the cluster advertises, which means genuine external access needs a stable, unique public address for every broker. The shared-IP approach that works for a normal HTTP service cannot express that, and shipping something that half-works over a protocol this stateful would be worse than shipping nothing.

Clusters are reachable from services in the same environment. If you need to reach one from outside, talk to us about what you are trying to do.

Managed does not mean "we ran the same install script you would have." It means the defaults that quietly fail at small scale were found and fixed before you met them.

Here is what a Postgres service on Simplifyd actually gives you.

More than one database

You can create additional databases on the same instance. Small teams run several services against one Postgres long before splitting it is worth the cost, and pretending otherwise just pushes people into sharing a single database across unrelated schemas.

Users with real boundaries

Create additional users with their own credentials. The obvious case is a read-only account for a BI tool or a nightly export — something that should never be holding your application superuser password.

Parameters you can tune

Postgres ships conservative defaults tuned for a machine that no longer exists. You can adjust parameters on your instance rather than filing a ticket and waiting.

Backups you can trigger

Automatic backups run on a schedule, and you can take one on demand — before a migration, before a risky deploy, before anything you would rather be able to undo.

simplifyd postgres backup create --service my-db

Why this list

None of these are exotic. They are the four things every team asks for within a month of putting real data somewhere, and the four things that most cheap managed offerings hold back for a higher tier.

The test of a managed database is not the first day. It is the day you need a second user and find out whether that was in the plan.

It shows up as latency you cannot optimise away in code. You can shave milliseconds off a query all week and lose them again on the way to the database.

Physics is not a tuning problem

You can cache aggressively at the edge, and you should. But the moment a request needs to write something, or read something a cache cannot serve, it goes back to wherever your database lives. No CDN fixes a write path.

Putting the whole stack — app, Postgres, Redis, Kafka, object storage — in the same place as your users is the only version of this that works.

Paying in the currency you earn in

The second problem has nothing to do with speed. Cloud bills arrive in dollars, on a card, at whatever the rate happens to be that month. For a business earning in naira, that turns a fixed infrastructure cost into a currency position nobody asked for.

We bill in naira and take local payment methods. Your infrastructure cost stops moving for reasons that have nothing to do with your infrastructure.

What we are building

• Managed Postgres, Redis and Kafka, with the defaults that fail quietly at small scale already fixed
• S3-compatible object storage that existing tooling talks to without changes
• Static sites, container deploys, and networking that includes real TCP and UDP proxying
• An MCP server, so AI coding agents can deploy to us directly

Building for this market should not mean accepting worse latency, or a bill denominated in someone else’s currency.

If you are running something here and paying an ocean of latency for it, we would like to hear what you are running.