cloudconfig: a backend for frontend developers

In a public post, I described a simple backend layer on Cloudflare, inspired by the ease of getting started with tools such as PocketBase and Supabase.

That is the direction behind cloudconfig. It is a beta project, currently built for Cloudflare. This article expands on the idea behind the post and the current project structure.

The repeated work is the problem

A small application can need the same field described in several places: the database, validation, an API response, a form and a client type.

Suppose a project record has a title and a published flag. When the title becomes required, the database and request validator need to agree. When only published records are public, the API needs an explicit rule.

The repetition makes even a modest backend harder to follow than it needs to be.

Let one model definition carry the shared contract

cloudconfig uses a TypeScript backend definition to connect model declarations to migrations, validated routes, access rules and a typed client.

The goal is to keep those pieces aligned. It is still the developer’s job to decide what a model means and which operations the application should permit.

A generated API is most useful when the rules behind it remain readable.

The frontend and an agent use the same boundary

A dashboard might ask to update a record. A coding or application agent might propose the same update. Both requests should pass through the application’s server-side validation and permissions.

A helpful interface can explain the proposed operation before execution. The backend must still reject an operation the caller is not allowed to perform.

That keeps the model’s business rules independent of the interface that happens to send the request.

Start with an actual deployment target

Cloudflare is cloudconfig’s current platform. Its services shape the present database and deployment integration.

Supporting other clouds well means examining database behavior, storage, background work and runtime assumptions. I treat that as infrastructure work that needs explicit adapters and verification, rather than a setting that can make platforms equivalent by itself.

For current setup details, use the cloudconfig docs. The project page gives a concise overview of the work.