Local development for Lovable apps without Docker

Lovable is great for the cloud-hosted development loop. The friction shows up when you want a copy running on your laptop, pointed at a local database, so you can iterate offline or test schema changes safely. The usual answer is Docker, and Docker is fine, but it is also slow to start, heavy on memory, and another thing to debug when something goes wrong.

The Layerbase CLI, powered by SpinDB under the hood, is the alternative: it runs the actual database binaries (Postgres, Valkey, Qdrant, the rest) directly on your machine, one command per engine. No Docker, no container layer, no networking weirdness. This post is how to use it to mirror a Lovable app locally.

Contents

• Install the Layerbase CLI
• Mirror your Lovable database
• Point the app at the local database
• Sync data from production
• Why no Docker

Install the Layerbase CLI

The Layerbase CLI is on npm. One command:

npm i -g layerbase

That installs lbase. The first time you create a database it downloads the engine binary (about 80MB for Postgres) and caches it. Subsequent creates of the same engine reuse the binary.

Mirror your Lovable database

In your Lovable project, you have one or more databases. For most apps that is just Postgres. Create a matching local one:

lbase create lovable-dev --engine postgresql --start

This boots a Postgres on a local port (5433 or the next free one). lbase url lovable-dev prints the connection string:

postgresql://localhost:5433/lovable_dev

If your Lovable app also uses Valkey for caching or Qdrant for vector search, add them:

lbase create lovable-dev-cache --engine valkey --start
lbase create lovable-dev-rag --engine qdrant --start

Three commands, three databases, total time under thirty seconds.

Point the app at the local database

One thing to be clear about: these DATABASE_URL and REDIS_URL values are read by the server side of an exported project (your Express, Hono, or Next.js API layer), not the browser SPA. A Lovable frontend never opens a database connection directly, so this workflow assumes you have synced the project to GitHub and are running its server code locally. Connect a Postgres database to a Lovable app covers why the browser cannot reach a database and where that server layer comes from.

In your Lovable repository (you can clone Lovable projects to a local git repo), create a .env.local that overrides the production URLs:

DATABASE_URL=postgresql://localhost:5433/lovable_dev
REDIS_URL=redis://localhost:6379
QDRANT_URL=http://localhost:6333
QDRANT_API_KEY=

Local Qdrant does not require an API key, so leave it empty. Local Valkey listens on the default Redis port without TLS, so use redis:// (one s).

Run your app's local dev command (usually pnpm dev or npm run dev) and the same code that talks to Layerbase Cloud in production now talks to your local Layerbase CLI instances. The connection string is the only thing that changes.

Schema and migrations

If you use Drizzle, run drizzle-kit push against the local URL to apply your schema:

DATABASE_URL=postgresql://localhost:5433/lovable_dev pnpm drizzle-kit push

If you use plain SQL migrations:

psql postgresql://localhost:5433/lovable_dev -f migrations/001_init.sql

The local database is empty until you do this, so the first step in any local dev session is "apply migrations." Add it as a script in package.json:

{
  "scripts": {
    "db:setup": "drizzle-kit push --config drizzle.config.dev.ts"
  }
}

Sync data from production

A common workflow is "pull a recent copy of production data into local so I can reproduce a bug." For a small Postgres this is two commands.

Dump from production:

pg_dump \
  --no-owner --no-acl --data-only \
  "$PROD_DATABASE_URL" \
  > prod-data.sql

Load into local:

psql postgresql://localhost:5433/lovable_dev < prod-data.sql

Be careful with PII. If your production has real user data, scrub it before loading locally. The shape that works for most apps:

update users set
  email = 'user-' || id || '@example.com',
  full_name = 'User ' || id;

Run that against the local copy after the load, before you start debugging. Now you have realistic-looking data without the legal liability of carrying real emails around on your laptop.

Why no Docker

Docker works. The issue is the overhead, not the correctness.

A Docker-based Postgres takes 5 to 10 seconds to start cold. The Layerbase CLI takes 1 to 2. On a workflow where you create and destroy local databases several times a day (test isolation, branch-specific schemas), that adds up.

Docker on macOS runs in a Linux VM, which means file I/O between the host and the container goes through a translation layer that is slower than direct file I/O on the same machine. For a small database the difference is invisible. For a 5GB Postgres it is noticeable.

Docker uses 1 to 2 GB of memory per container even when idle, because the daemon and the VM are always running. The Layerbase CLI uses memory only when an engine is actually running, and stops it when you say so.

Docker is also another tool to debug when things go wrong. Networking, volumes, port mapping, image versions. The Layerbase CLI is "did the process start, yes or no." The failure modes are simpler.

None of this matters if you already have Docker installed and working. If you do not, the Layerbase CLI is a smaller download and a simpler workflow. What is the Layerbase CLI? has the rest.

Useful Layerbase CLI commands

The five I use most:

lbase list                              # all databases, running or stopped
lbase url lovable-dev                   # print the connection string
lbase stop lovable-dev                  # stop without deleting data
lbase start lovable-dev                 # restart, same data, same port
lbase destroy lovable-dev               # remove permanently

For a longer workflow including multi-engine and connecting from external tools, see Managing multiple databases locally.

Wrapping up

The short version of "develop a Lovable app locally":

1. npm i -g layerbase
2. lbase create lovable-dev --engine postgresql --start
3. Put DATABASE_URL=postgresql://localhost:5433/lovable_dev in .env.local
4. Run your app, develop against the local database
5. Push your changes back into Lovable when they work

The point of mirroring locally is not to replace Lovable. It is to give yourself a fast iteration loop for the parts that touch the database. Schema changes, query tuning, bug reproduction, all of those go faster when the database is on the same machine as your editor. Once it works locally, deploy with confidence.

If production is still on Supabase and you are eyeing the move, Migrating from Supabase to Layerbase covers the database and the auth users in one pass.