Introduction

A blog needs more than a page that displays posts. It needs somewhere to store them, validation for new posts, and rules that keep drafts private.

CloudConfig describes those decisions in one TypeScript file. Your database schema, REST API, typed client, and API documentation use that same definition.

Keep Your Model and API in Sync

This model lets visitors list published posts:

import { defineBackend, model, t } from '@cloudconfig/core'

export const config = defineBackend({
  models: {
    post: model(
      {
        title: t.text().required(),
        published: t.boolean().default(false),
      },
      {
        access: {
          list: ({ where }) => where('published', 'eq', true),
        },
      },
    ),
  },
})

CloudConfig provides a posts table and an /api/posts endpoint. The endpoint returns published posts; other operations stay denied until you allow them.

When you add a field, generate and review a SQL migration. The API and client types pick up the new field from the config.

Start Locally, Then Choose a Host

Use CloudConfig inside Nuxt or Next.js, or run it as a standalone API. Local development uses SQLite and needs no cloud account.

When you are ready to deploy, choose Cloudflare, Vercel, or Azure. Application hosting, the production database, and file storage have separate settings, so you can move the app before migrating its data.

CloudConfig is in beta. Its APIs may change before the first stable release.

Build Your First API

Start with the Quickstart. In about ten minutes, you will run a blog API locally and add a field to a post.

Already have a project? Read Essentials for models, access rules, and typed requests.

Install the CLI

The Quickstart runs the CLI without installing it globally. If you prefer a global command, use Node.js 22.12 or newer and install the beta:

npm install -g @cloudconfig/core@beta
cloudconfig --help

pnpm add -g @cloudconfig/core@beta
cloudconfig --help