Ploy vs Lovable: where to run the app Lovable built

Lovable is good at the part that used to take weeks: describe an app, get a working React frontend. The part it does not solve is what happens when that app needs to run for real users for a long time, with data you own, background jobs, scheduled work, and a deployment pipeline your team controls.

That is the comparison. Lovable generates the application. Ploy is an open-source serverless cloud where you deploy and run it, with a database, queues, cron, durable workflows, managed auth, and an AI gateway included, and with the option to self-host all of it. They are not competitors so much as two halves of a workflow, and this post explains how to put them together.

The short version

Hosting Lovable-generated apps on Ploy

Lovable can sync a project to a GitHub repository. Once the code is there, the Lovable app is a normal Vite React app, and deploying it on Ploy is three lines of configuration.

1. Connect the repository

Create a project in the Ploy dashboard and connect the GitHub repository Lovable writes to.

2. Add a ploy.yaml

For a frontend-only app:

kind: static
build: npm run build
out: dist

kind: static
build: npm run build
out: dist

Push, and Ploy builds and deploys. Every push Lovable makes to the repository deploys again, and every branch gets a preview URL.

3. Give it a backend when you need one

This is where Ploy earns its place. Switch the project to kind: dynamic, add a worker at worker/index.ts, and declare the resources the app needs:

kind: dynamic
build: npm run build
out: dist
assets:
  binding: ASSETS
  not_found_handling: single-page-application
  run_worker_first:
    - /api/*
db:
  DB: default
auth:
  binding: AUTH_DB
cron:
  DAILY_DIGEST: "0 9 * * *"

kind: dynamic
build: npm run build
out: dist
assets:
  binding: ASSETS
  not_found_handling: single-page-application
  run_worker_first:
    - /api/*
db:
  DB: default
auth:
  binding: AUTH_DB
cron:
  DAILY_DIGEST: "0 9 * * *"

The worker serves /api/* next to the generated frontend, on the same origin, with no CORS:

export default {
  async fetch(request, env) {
    const url = new URL(request.url);

    if (url.pathname === "/api/items") {
      const { results } = await env.DB.prepare(
        "SELECT id, title FROM items ORDER BY id DESC",
      ).all();
      return Response.json({ items: results });
    }

    return new Response("Not Found", { status: 404 });
  },
  async scheduled(event, env) {
    await env.DB.prepare("DELETE FROM items WHERE expires_at < ?")
      .bind(Date.now())
      .run();
  },
} satisfies Ploy;

export default {
  async fetch(request, env) {
    const url = new URL(request.url);

    if (url.pathname === "/api/items") {
      const { results } = await env.DB.prepare(
        "SELECT id, title FROM items ORDER BY id DESC",
      ).all();
      return Response.json({ items: results });
    }

    return new Response("Not Found", { status: 404 });
  },
  async scheduled(event, env) {
    await env.DB.prepare("DELETE FROM items WHERE expires_at < ?")
      .bind(Date.now())
      .run();
  },
} satisfies Ploy;

Install @meetploy/vite, spread ploy() into the Vite plugins, and point the dev script at ploy vite dev so local development gets the same bindings. The items table comes from a .sql file in migrations/, applied on deploy. The auth: binding exposes sign-up, sign-in, and session endpoints at /_ploy/auth/*, with @meetploy/auth-react components for the frontend.

You can keep prompting Lovable for frontend changes; the worker and ploy.yaml are ordinary files in the same repository.

What Ploy adds that a builder cannot

• A database you own. SQLite per project, with migrations tracked in Git and applied on deploy, instead of a schema that lives in a third-party console.
• Work that is not a request. Queues with retries, cron triggers down to per-second schedules, and durable workflows whose steps survive restarts.
• Users. Managed email/password auth with secure cookie sessions, enabled by one auth: block.
• AI without keys. ai: true gives the worker env.AI.run() and an OpenAI-compatible endpoint.
• A real pipeline. Preview URL per branch, build logs, rollbacks, and skew protection on by default.
• An exit. Ploy is AGPLv3 and self-hostable. If you outgrow hosted Ploy, run the same platform on your own servers.

Where Lovable stays in the loop

Lovable remains the fastest way to iterate on the UI. Nothing about deploying on Ploy stops that: Lovable keeps pushing to the repository, Ploy keeps deploying each push. If Lovable's hosted preview is enough for a prototype, use it; move to Ploy when the app needs a backend you control or a deployment process your team owns.

Frequently Asked Questions

Can I deploy a Lovable app on Ploy without changing code?

Yes. A frontend-only Lovable app deploys with kind: static. Backend bindings are opt-in.

What if the Lovable app already uses a hosted backend-as-a-service?

Keep it. Ploy serves the frontend and your worker can call any external API. Add a db binding only when you want data inside Ploy.

Does Ploy work with other AI builders?

Any tool that produces a repository on GitHub works the same way. Ploy also hosts its own Git, so an agent can push to Ploy directly without a GitHub account; see Ploy Git.

What does it cost to host a Lovable app on Ploy?

The hosted Free plan covers up to 3 repositories. Pro is $10 per month with custom domains and unlimited repositories. Self-hosting is free.

Get started

• Deploy your Lovable app on Ploy free
• Read the Vite docs for the worker setup
• Next: Launch an app with a database included