How do I connect a managed backend to my project?

Think about what a backend actually is for a typical app: a database to store rows, a way for users to sign in, somewhere to put files, and ideally live updates so two browser tabs stay in sync. None of that is conceptually hard — but wiring it up traditionally means standing up a service, managing its credentials, and keeping those credentials out of your git history and your client bundle. For a prototype that might never ship, that ceremony is pure friction.

LingCode Cloud's answer is a managed backend per project. "Managed" means LingCode runs the Postgres, the auth, the storage, and the email — you never create an account on a third-party service or copy a secret key. "Per project" means each folder you connect gets its own isolated database (a private Postgres schema with row-level security), so two projects can't see each other's data even though they share the same infrastructure.

The connection itself is deliberately small: it teaches your project's agent how to reach the backend. After that, you talk to the agent in plain language — "let users sign up and save their notes" — and it provisions tables and writes the code. This tutorial explains what "connect" really does, walks the steps, and shows where to manage the result.

What you'll learn

• What the Connect Backend action actually does (and what it doesn't)
• How a backend is tied to a project — and why reopening the folder reuses it
• What you get out of the box: database, auth, storage, realtime, vector search
• How to drive it from a prompt, and how to manage it in the web console
• Disconnecting, reconnecting, and the one gotcha to avoid

What "Connect Backend" really does

Two things happen when you connect a project, and it's worth knowing them separately because they fail and succeed independently:

• It writes .mcp.json in your project folder. That file registers a lingcode-cloud MCP server — the bridge the agent uses to talk to your backend. It carries your account token and a project key (a stable hash of the folder's path), so the agent's calls are scoped to this project's backend.
• It provisions the backend. Connecting eagerly creates the managed Postgres backend for the project right then, so it shows up in your console immediately. (If that network call hiccups, it's not fatal — the agent will provision on first use instead.)

The project key is the important idea. Because it's derived from the folder path, reopening the same folder and reconnecting reuses the same backend — your data is still there. Move or rename the folder and the key changes, so LingCode treats it as a new project (the old backend isn't deleted; this project just no longer points at it).

Connect it, step by step

1. Sign in to your LingCode account in the Mac IDE (the account menu in the activity bar). The backend is created under this account.
2. Open your project folder — any local folder. The backend attaches to this folder's path.
3. Choose Account → LingCode Cloud → Connect Backend to This Project. You'll get a confirmation that a managed backend was created and .mcp.json was written. (Connecting again later just refreshes the token — it's safe and idempotent.)
4. Open a new Claude (Native) session (new, so it re-reads .mcp.json and picks up the lingcode-cloud tools).
5. Ask for something that needs persistence or accounts, for example:
   "Build a notes app where users sign up and each person only sees their own notes. Use lingcode-cloud for the backend."

From there the agent calls provision_backend (ensuring the backend exists), apply_migration (creating the tables your app needs), and then writes the app against the backend's data API. You don't paste any keys — the tools are already authenticated through the connection.

What you get out of the box

A connected backend is not just a database. Every project backend ships with:

• Postgres with row-level security — real SQL tables, with per-user isolation so a signed-in user only reads and writes their own rows.
• Built-in auth — email/password, passwordless magic-link, email one-time codes, and social login (Google, GitHub, with Apple available). Nothing to configure for the managed providers.
• File storage — upload and serve files with a public URL.
• Realtime — subscribe to a table and get live INSERT/UPDATE/DELETE events (RLS-filtered), so chat, collaborative lists, and dashboards update without polling.
• Vector search (pgvector) — store embeddings and rank rows by similarity, for "search my notes by meaning", RAG, and recommendations.
• Transactional email — send mail with no API key or sender setup.

The agent knows about all of these and will reach for the right one — it'll subscribe to realtime instead of polling, add a vector column when you ask for semantic search, and so on.

Manage it in the console

Everything the agent provisions is visible (and editable) at lingcode.dev/backends, signed in with the same account. The console gives you a project switcher and, per backend:

• Database — browse tables, sort and page through rows, and insert / edit / delete rows directly (the owner view bypasses RLS, like a table editor).
• Authentication — see who has signed up; remove a user.
• SQL — run read-only queries, or apply a migration to change the schema.
• Settings — rename the project, copy the connection details, or delete the backend.

The connection details here (the data URL and the anon key) are also what you'd paste into another MCP client — Claude Desktop or Cursor — to reach the same backend from outside the IDE.

Disconnect, reconnect, and the gotcha

Account → LingCode Cloud → Disconnect Backend removes the lingcode-cloud entry from .mcp.json. It does not delete the backend or its data — reconnecting the same folder later picks the same backend right back up (remember: the project key is the folder path). To actually destroy a backend and its data, use Delete backend in the console's Settings.

The one gotcha worth repeating: the backend belongs to the account the IDE is signed into, keyed by the folder path. If a project's backend "disappears", check (1) that the IDE and the web console are the same account, and (2) that the folder hasn't moved. Both are easy to verify and both explain the most common "where did it go" moment.

What's next