[{"data":1,"prerenderedAt":131},["ShallowReactive",2],{"project-\u002Fprojects\u002Fcloudconfig":3,"project-writing-\u002Fprojects\u002Fcloudconfig":24,"mdc-njt9l1-key":41},{"slug":4,"title":5,"description":6,"body":7,"category":8,"sources":9,"name":4,"order":16,"status":17,"stack":18,"website":12,"featured":22,"path":23},"cloudconfig","cloudconfig — a project by Dennis Adriaansen","A TypeScript configuration layer for models, APIs, access rules and backend deployment on Cloudflare.","\n## A backend for frontend developers\n\ncloudconfig is my backend infrastructure project. Its starting point is a familiar frustration: building an interface is straightforward, but the database, validation, routes, access rules and deployment need to agree with each other.\n\nThe aim is to express those shared decisions in a TypeScript backend definition and derive the repetitive parts from it.\n\n## One definition, several connected pieces\n\nThe current project describes model definitions, database migrations, validated REST routes, authentication, access rules and a typed client. The same model definition gives the frontend and backend a common contract.\n\nNuxt applications use the Nuxt integration. A standalone API is also part of the project. The deployment target today is Cloudflare.\n\n## Where the boundaries belong\n\nA typed client helps a developer call an API correctly. Access rules still belong on the server. A generated endpoint needs to enforce the application’s rules whether the request comes from a dashboard, a script or an agent.\n\nThat distinction is especially useful when a natural-language interface proposes an action. The proposal is an input to the application, and the backend determines which operations are permitted.\n\n## Current status\n\ncloudconfig is in beta, and its API can change before a stable release. Cloudflare is the current platform; broader cloud portability is a direction for the project, not a promise that other platforms already have full support.\n\nRead [the project documentation](https:\u002F\u002Fcloudconfig.dev\u002Fdocs) for current setup and deployment details. My article on [a backend for frontend developers](\u002Fblog\u002Fcloudconfig-a-backend-for-frontend-developers) connects that work to a public post about the idea.\n","Backend infrastructure",[10,13],{"label":11,"url":12},"cloudconfig documentation","https:\u002F\u002Fcloudconfig.dev\u002Fdocs",{"label":14,"url":15},"My public post about a simple backend layer on Cloudflare","https:\u002F\u002Fx.com\u002FDennisAdriaans\u002Fstatus\u002F2106081787013193818",2,"Beta",[19,20,21],"TypeScript","Cloudflare","D1",false,"\u002Fprojects\u002Fcloudconfig",[25],{"slug":26,"title":27,"description":28,"body":29,"category":30,"sources":31,"date":35,"tags":36,"language":39,"draft":22,"project":4,"path":40},"cloudconfig-a-backend-for-frontend-developers","cloudconfig: a backend for frontend developers","The idea behind Dennis Adriaansen’s cloudconfig project: keep models, validation, access rules and deployment connected.","\nIn 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.\n\nThat 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.\n\n## The repeated work is the problem\n\nA small application can need the same field described in several places: the database, validation, an API response, a form and a client type.\n\nSuppose 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.\n\nThe repetition makes even a modest backend harder to follow than it needs to be.\n\n## Let one model definition carry the shared contract\n\ncloudconfig uses a TypeScript backend definition to connect model declarations to migrations, validated routes, access rules and a typed client.\n\nThe 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.\n\nA generated API is most useful when the rules behind it remain readable.\n\n## The frontend and an agent use the same boundary\n\nA 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.\n\nA helpful interface can explain the proposed operation before execution. The backend must still reject an operation the caller is not allowed to perform.\n\nThat keeps the model’s business rules independent of the interface that happens to send the request.\n\n## Start with an actual deployment target\n\nCloudflare is cloudconfig’s current platform. Its services shape the present database and deployment integration.\n\nSupporting 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.\n\nFor current setup details, use [the cloudconfig docs](https:\u002F\u002Fcloudconfig.dev\u002Fdocs). The [project page](\u002Fprojects\u002Fcloudconfig) gives a concise overview of the work.\n","Backend & agents",[32,34],{"label":33,"url":15},"My public cloudconfig post on X",{"label":11,"url":12},"2026-10-12",[4,20,19,37,38],"backend","access rules","en","\u002Fblog\u002Fcloudconfig-a-backend-for-frontend-developers",{"data":42,"body":43},{},{"type":44,"children":45},"root",[46,55,61,66,72,77,82,88,93,98,104,109],{"type":47,"tag":48,"props":49,"children":51},"element","h2",{"id":50},"a-backend-for-frontend-developers",[52],{"type":53,"value":54},"text","A backend for frontend developers",{"type":47,"tag":56,"props":57,"children":58},"p",{},[59],{"type":53,"value":60},"cloudconfig is my backend infrastructure project. Its starting point is a familiar frustration: building an interface is straightforward, but the database, validation, routes, access rules and deployment need to agree with each other.",{"type":47,"tag":56,"props":62,"children":63},{},[64],{"type":53,"value":65},"The aim is to express those shared decisions in a TypeScript backend definition and derive the repetitive parts from it.",{"type":47,"tag":48,"props":67,"children":69},{"id":68},"one-definition-several-connected-pieces",[70],{"type":53,"value":71},"One definition, several connected pieces",{"type":47,"tag":56,"props":73,"children":74},{},[75],{"type":53,"value":76},"The current project describes model definitions, database migrations, validated REST routes, authentication, access rules and a typed client. The same model definition gives the frontend and backend a common contract.",{"type":47,"tag":56,"props":78,"children":79},{},[80],{"type":53,"value":81},"Nuxt applications use the Nuxt integration. A standalone API is also part of the project. The deployment target today is Cloudflare.",{"type":47,"tag":48,"props":83,"children":85},{"id":84},"where-the-boundaries-belong",[86],{"type":53,"value":87},"Where the boundaries belong",{"type":47,"tag":56,"props":89,"children":90},{},[91],{"type":53,"value":92},"A typed client helps a developer call an API correctly. Access rules still belong on the server. A generated endpoint needs to enforce the application’s rules whether the request comes from a dashboard, a script or an agent.",{"type":47,"tag":56,"props":94,"children":95},{},[96],{"type":53,"value":97},"That distinction is especially useful when a natural-language interface proposes an action. The proposal is an input to the application, and the backend determines which operations are permitted.",{"type":47,"tag":48,"props":99,"children":101},{"id":100},"current-status",[102],{"type":53,"value":103},"Current status",{"type":47,"tag":56,"props":105,"children":106},{},[107],{"type":53,"value":108},"cloudconfig is in beta, and its API can change before a stable release. Cloudflare is the current platform; broader cloud portability is a direction for the project, not a promise that other platforms already have full support.",{"type":47,"tag":56,"props":110,"children":111},{},[112,114,122,124,129],{"type":53,"value":113},"Read ",{"type":47,"tag":115,"props":116,"children":119},"a",{"href":12,"rel":117},[118],"nofollow",[120],{"type":53,"value":121},"the project documentation",{"type":53,"value":123}," for current setup and deployment details. My article on ",{"type":47,"tag":115,"props":125,"children":126},{"href":40},[127],{"type":53,"value":128},"a backend for frontend developers",{"type":53,"value":130}," connects that work to a public post about the idea.",1794481660795]