What VULK Builds Behind a Full-Stack App: Database, Sign-In and API, Checked Live

Verified on October 10, 2026, against the code VULK runs today and against live endpoints.

When you ask VULK for an app that has to remember things, such as a store, a booking tool or a CRM, it does not stop at screens. It builds three things behind them: a database of the project's own, a sign-in system for the people who will use the app, and a REST API that the screens talk to. All three run on VULK's managed backend at api-backend.vulk.dev, and you do not set up a server, a database or an auth provider.

This post shows each part the way it actually works. Every number below comes from one of three places: the code that generates and serves these apps (read on October 10, 2026), the public health endpoint of the backend, and live requests against a store that is public in the VULK showcase. Nothing here is a benchmark we ran on someone else's product.

The frontend VULK writes

A web app comes out as a React project built with Vite. The versions are pinned in the generator rather than left to float, so the project you preview is the project you export:

When an app needs data, VULK adds a typed client file to the project. The screens never build URLs or tokens by hand; they call that client, and the client calls the backend.

One database per project

The backend gives every project its own PostgreSQL database, identified by a short id: proj_ followed by the first eight hexadecimal characters of the conversation that built the app. The id stays the same through every edit, so your app keeps its data when you ask for a change.

The backend publishes a health endpoint that anyone can read. On October 10, 2026 at 22:34 UTC it answered:

{
  "status": "ok",
  "service": "vulk-api-engine",
  "database": "connected",
  "projects": 1440
}

That is 1,440 provisioned project databases on the engine at that moment.

What a generated table looks like

VULK decides the tables from what your app needs (products, orders, appointments) and adds three columns of its own:

• id, a text primary key
• created_at, a timestamp filled in by the database
• user_id on tables where each row belongs to one signed-in person

Every other column takes one of five types: text, number, integer, boolean or datetime. Table and column names use lowercase letters, digits and underscores, start with a letter and stop at 48 characters. The API answers in camelCase, so created_at reaches your screens as createdAt.

Schema changes only ever add. When an edit needs a new table or column, the backend adds it. Dropping a column or changing its type is never done automatically, because that is the change that deletes data.

The REST API, route by route

Each table gets the same set of routes under the project's address:

Lists come back in one envelope, { data, meta: { total, page, perPage, totalPages } }. The generated client reads 100 rows per page and stops at 1,000, and it sends bulk inserts in chunks of 1,000. Each project accepts 100 requests per minute from each client address, and the backend says so in every response with an X-RateLimit-Limit: 100 header.

Who can read and write what

This is the part generated backends most often get wrong, so it is worth being exact. A table with no declared access policy is closed. VULK first gives the whole app one of four shapes:

• Private accounts: each person signs in and sees only their own rows.
• Team accounts: a team works on the same rows, and people join by invite.
• Public: no accounts at all.
• Owner panel: visitors, plus one area that only the owner can open.

Then it sets each table on its own. A table can be read publicly, with the project's API key, by a signed-in user or only by the owner, and writes have the same options plus "anyone", for things like a contact form. Anonymous writes are capped at 20 per minute per address. Fields are private unless the app's plan says otherwise.

Here is that policy on a live app. LUMA is a fashion store in the showcase that runs on this backend at proj_266b7c3c. We sent these requests without signing in, on October 10, 2026:

The catalogue is public, because a shop has to show its products. Orders need a signed-in customer. The accounts table is not exposed as a table at all.

Sign-in for the people who use your app

Every full-stack app gets its own user accounts, separate from your VULK account. The generated client covers register, sign in, "who am I" and password reset. The backend also has routes for refresh, sign out and password change:

• Passwords are hashed with PBKDF2-SHA256, 100,000 iterations and a 16-byte random salt.
• The session lives in the browser and is sent as a bearer token. Any 401 clears it, so the app never keeps a session the server has already rejected.
• The person who owns the project is the admin; everyone who registers is a regular user.
• Registration can be open, or invite-only with codes that work once and expire after seven days.

In the studio, each project's dashboard has a Backend tab with an overview, the database, the app's users, the API and its secrets.

Keys and secrets

Each project gets an API key of the form vk_ followed by 64 hexadecimal characters, stored encrypted with AES-256-GCM. The published bundle carries no key: the address of the backend is injected into the page at load time, and nothing that would let a visitor act as the owner is shipped to the browser. Secrets your app needs, such as a third-party API token, are write-only. You can set or replace one, but nobody can read it back, and each is limited to 8 KB.

Publishing and taking the code with you

Publishing is one click. VULK builds the production version inside the same isolated machine that ran your preview, then serves it at <name>.vulk.space over HTTPS. The name you pick stays yours. If you unpublish, the site goes offline and the address is kept for that project. The backend address is bound into both the preview and the published build, so the published app talks to the same database you tested.

The code is yours too. Every paid plan can download the whole project as a ZIP or push it to a new GitHub repository, private or public. The GitHub export never force-pushes, and it takes up to 1,000 files and 8 MB per push.