lavela

About Lavela

Connect the app you built, deploy it, and manage its servers, domains and payments. Use the web console and your AI tools to work on the same projects.

On this page

Service reference

The detailed reference below is shared with connected AI tools. Use the guide above for connection steps for your app.

lavela — launch and operate the app you built, from one conversation (MCP-first).

This page is for both humans and AI agents (Claude Code, Cursor, or any MCP client) landing here from a blog post, a shared link, or a search — it's the data the lavela.capabilities MCP tool returns, with what is not open yet (launching ads) or limited (rollback: web-hosting sites only) marked.

Technical connection settings

Any MCP client that supports remote servers + browser sign-in (OAuth) — add this URL, then sign in when your client opens the browser (no token to paste):

https://console.lavela.dev/api/mcp

That connection has the core tools (marked (core) below — deploy a repo and operate it). For every tool — ad drafts and reports, cron schedules, preview environments, security scans, legal documents, volumes / storage, one-off jobs, image push — connect with:

https://console.lavela.dev/api/mcp/all

A client that rejects tool names with a period (Lovable shows every lavela tool as "Invalid") connects to the same core tools at an address whose names have none — lavela.account_status is lavela_account_status there:

https://console.lavela.dev/api/mcp/compat

Claude Code, in one line (use https://console.lavela.dev/api/mcp/all for every tool):

claude mcp add --transport http --scope user lavela https://console.lavela.dev/api/mcp

Already added lavela before? An old entry (an old address, or a leftover token header) can stop the browser sign-in, so remove it first, from each place Claude Code keeps it, then add it again:

claude mcp remove lavela -s user
claude mcp remove lavela -s local
claude mcp remove lavela -s project

Or let the CLI wire up Claude Code, Cursor, Windsurf and Claude Desktop for you:

npx @lavela/cli connect

A browser opens to console.lavela.dev, you sign in and click "Authorize & connect," and the CLI writes the connection into your client configs (no token to copy-paste). Reconnect an already-open Claude Code session with /mcp. Once connected, start with lavela.account_status — it shows your balance, whether the free welcome credit has been added (that happens automatically — there is no claim step), and what to do next. A connected client also lists a guided prompt, launch-my-app ("Launch my app"; in Claude Code, /mcp__lavela__launch-my-app), that walks the first launch step by step.

No separate dashboard-then-docs detour: the point of lavela is that an AI agent already in your coding session can provision infrastructure and accept payments through the same kind of tool call it already makes for everything else (launching ads through lavela is not open yet).

Suggested workflow

  1. account_status — Terms accepted? free welcome credit (added automatically) and what it covers? balance? (links for the user)
  2. analyze_stack — what the repo is + its lavela lane (hosting = a web frontend, compute = an app with its own server)
  3. launch_saas — create the project; its next_step picks the deploy for THIS account — follow it
  4. provision_compute_from_repo → compute_build_status (confirm first — paid from the wallet; poll until ok/failed, usually 3–6 minutes; next_step carries the fix — compute_rebuild starts a build again with its exact settings; to redeploy after a push: compute_build_status {projectId, service} → compute_rebuild) — on the free welcome credit EVERY app deploys this way, and so does any app with its own server (Java/Go/Python/Node backends, multi-service); provision_compute runs an image you pushed instead (paid from the wallet)
  5. provision_hosting → get_status (poll) → check_health — a web frontend (static/Vite/Next) on a funded account
  6. project_overview — later, or in a new conversation: URLs, server states + machine ids, builds, domain, data and balance in one call; its next_step is the fix (check_health confirms it answers)
  7. provision_database — managed Postgres, wired into the server (limit-bounded, no usage charge today); no managed Redis — bring your own REDIS_URL (set_compute_secret) or run valkey/redis as your own server (provision_compute)
  8. set_compute_secret — inject API keys + secrets (write-only, encrypted), then run_compute_job for DB migrations (e.g. alembic upgrade head)
  9. compute_wire (advanced: /api/mcp/all) — the private address one of your services uses to reach another (api ↔ worker ↔ db; it answers only while that server runs — keep a shared database always on); get_logs / get_errors to debug
  10. security_scan (advanced) — check the repo for dependency vulnerabilities + committed secrets right after the first deploy (poll security_scan_status)
  11. compliance_generate (advanced) — privacy policy + terms
  12. connect_stripe — start accepting payments (KYC 1-5d)
  13. create_checkout — charge customers (settles to you in full, no lavela fee)
  14. provision_domain → diagnose_domain — connect a custom domain you already own (free — no purchase, DNS only), then see exactly what to fix at the registrar
  15. provision_email — inbox-safe sending on the domain
  16. ads_draft (advanced) — draft a campaign for later (you write the copy); launching ads through lavela is not open yet

Not a fixed pipeline — skip what you don't need, and every tool result carries a next_step suggesting what to call next.

Environment variables and .env files

An app's variables are of two kinds, set in two places — and an AI agent never reads a .env value:

  • Secrets (API keys, DATABASE_URL, tokens) — lavela.set_compute_secret: encrypted and write-only, reaching the server when it starts.
  • Public build settings (names starting NEXT_PUBLIC_, VITE_, REACT_APP_, …: the Supabase URL and anon key a web frontend bakes into the page every visitor downloads) — lavela.set_build_vars: readable, never a secret, used by the next build (then lavela.compute_rebuild). A page that loads blank usually means a public value is missing.
  • A whole .env — lavela.env_link: returns the way that works for the account to send it, with public entries stored as build settings and the rest as secrets: a command for the user to run in the project folder, npx @lavela/cli env push --project <id> (variable names only on screen, one Allow click in their browser), or a console page where they paste the file. Values go from the user's computer or browser straight to lavela, never through the agent or the chat.

An account without public build settings yet is refused with BUILD_VARS_UNAVAILABLE; the public values then go in the repo (for example a committed .env.production — never a secret key). More: console.lavela.dev/docs/mcp.

Available tools

Tools marked (core) are in the default connection; the others need https://console.lavela.dev/api/mcp/all. Details behind every tool description: console.lavela.dev/docs/mcp.

Not listed: tools that are not open to customer accounts yet — the switch they depend on is off today — lavela.configure_service, lavela.link_services, lavela.volume_extend, lavela.volume_snapshots, lavela.template_status, lavela.template_rotate, lavela.template_upgrade, lavela.template_lifecycle_status, lavela.volume_restore, lavela.public_port_link, lavela.egress_ip_link, lavela.provision_storage.

Account and welcome credit

4 tools
  • lavela.account_status (core) — Terms/consent, free welcome credit (auto-added; remaining; grace stop time), wallet balance (free vs paid vs held), compute pause + next steps with links (free)
  • lavela.trial_claim_link — link that gets the user the free welcome credit (added automatically once they accept the Terms in the browser) (free)
  • lavela.topup_link (core) — link where the user adds funds / saves a card (free — the user pays in the console, never through the agent)
  • lavela.resume_compute (core) — lift a low-balance compute pause after a top-up (then start servers with compute_lifecycle) (free)

App analysis

4 tools
  • lavela.ping — confirm the connection (free)
  • lavela.capabilities — this — list what lavela can do (free)
  • lavela.analyze_stack (core) — detect a repo's framework + language and the lavela lane that runs it (hosting or compute); warns when its data (SQLite, uploads) would be lost on a server's wiped disk (free)
  • lavela.list_templates — browse launch templates (free)

Projects and deployment

2 tools
  • lavela.launch_saas (core) — create a project + decide how it deploys for this account (next_step) (free)
  • lavela.provision_hosting (core) — deploy a web frontend (Next/Vite/static) to a live URL — funded accounts; on the welcome credit use provision_compute_from_repo (needs a funded account (not the welcome credit))

Server operations

29 tools
  • lavela.compute_exec_history — read owned command audit metadata without command text or output (free)
  • lavela.compute_status — the user's plan, usage limits + what's running (free)
  • lavela.compute_list — the machines running in a project (ids for lifecycle / destroy) (free)
  • lavela.compute_estimate — what a server size costs a month before you commit — sleeping when idle: a base fee while asleep plus the always-on rate while awake, never more than that rate; always on: that rate (free)
  • lavela.provision_compute — run ANY container (Java/Go/Node/Python/backend/multi-service) — build+push an image, lavela runs it on a live URL (a database/cache image such as postgres or valkey runs private and always on, once the user confirms its always-on price: no URL, reached by your other servers at its private address). Supports mounts (attach a provision_volume disk) + secrets from set_compute_secret. (per server by its size, billed by the second: sleeping when idle, a base fee while asleep and its always-on rate while awake (never more than that rate a month); always on, that rate; sizes above the smallest need a paid top-up first (prices: /pricing) — confirm first)
  • lavela.provision_compute_from_repo (core) — same, but lavela BUILDS the image from a GitHub repo (no local Docker needed); a database/cache port (5432, 6379, …) runs private and always on, once the user confirms its always-on price (per server by its size, billed by the second: sleeping when idle, a base fee while asleep and its always-on rate while awake (never more than that rate a month); always on, that rate; sizes above the smallest need a paid top-up first (prices: /pricing) — confirm first)
  • lavela.push_image — the user pushes a locally-built image with one command (npx @lavela/cli push; nothing secret passes through the agent) so a PRIVATE image runs without publishing it publicly — then provision_compute the ref it prints (free)
  • lavela.deploy_link (core) — a one-time browser link the USER opens to deploy LOCAL-only code (connect GitHub or drag-drop the folder) — for when the agent can't push the code itself. Dragging a folder in needs a paid top-up and an existing project: on the free welcome credit the page deploys from GitHub only, so put the code on GitHub first (free)
  • lavela.compute_lifecycle (core) — start / stop / restart a server (machine ids from project_overview) (free)
  • lavela.compute_always_on (core) — switch a server between always on (never sleeps) and sleeping when idle, in place — no rebuild (a database/cache server stays always on: stop it instead) (switching is free; always on pays its size's always-on rate, while a sleeping server pays a base fee while asleep and that rate while awake — confirm before turning it on)
  • lavela.compute_set_size — change a server's size in place (512 MB up to 8 GB; it restarts once, no rebuild) — sizes above 512 MB need a paid top-up (an account back on the welcome credit after a full refund needs a new one) (a bigger size raises its always-on rate (what a sleeping server pays while awake, and its monthly cap), a smaller one lowers it — confirm the new price first)
  • lavela.set_compute_secret (core) — set encrypted secrets (API keys, JWT, DATABASE_URL) on a service — write-only through lavela: it never shows them back, though code running in your server can read its own environment; applying restarts the service's running server only, never a one-off job or a build; a service name nothing runs under yet starts a new service — the result says createdService and, next to a close name (wbe for web), warns SIMILAR_SERVICE, so confirm the name with the user; ${{…}} references are refused (not available yet); unset removes names (a name that is not set is a no-op), and PORT, PATH, HOME, HOSTNAME, PRIMARY_REGION, FLY_* and LAVELA_* names are refused (VARIABLE_RESERVED) (free)
  • lavela.set_build_vars (core) — store PUBLIC build settings (VITE_/NEXT_PUBLIC_… — the Supabase URL and anon key, never a secret key) that a web frontend's bundler bakes into the page every visitor downloads: readable, applied by the NEXT build (then lavela.compute_rebuild — nothing restarts), a name without a public prefix or a secret-looking name or value is refused; with no vars or unset it returns the current set; secrets go to set_compute_secret (free — the rebuild that applies them is a build: confirm first)
  • lavela.env_link (core) — send the USER's whole .env to lavela without the agent seeing a value: public entries become build settings, the rest write-only server secrets — a command to run in their project folder (npx @lavela/cli env push, names only on screen, one Allow click in their browser) where the account has it, else the server page where they paste it where the account has that; the answer says which routes the account has, and where it has neither it lists the ones that work everywhere (set_compute_secret with values the user chooses to tell you, write-only; public VITE_/NEXT_PUBLIC_ values in a committed .env.production) (free)
  • lavela.compute_wire — the private address (.internal) one of your services uses to reach another on your account's private network — read-only; it answers only while that server runs (a sleeping or stopped one does not) (free)
  • lavela.run_compute_job — run a one-off job (DB migrations / seeds / backfills); short → exitCode + teardown, long → status:"running" (finishes in background, do NOT re-run) (paid from the wallet — a run past ~180s keeps its server billed until destroy_compute removes it — confirm first)
  • lavela.schedule_create — run a command REPEATEDLY on a cron cadence (nightly backups, weekly digests) — same primitive as run_compute_job, fired automatically (billed EVERY firing — confirm the cadence first)
  • lavela.schedule_list — a project's cron schedules — cadence, next run, last outcome (free)
  • lavela.schedule_update — edit a schedule's command/cadence, or pause/resume it (free)
  • lavela.schedule_delete — permanently remove a cron schedule (free)
  • lavela.schedule_run_now — trigger one schedule immediately, outside its normal cadence (for testing) (billed like a normal firing)
  • lavela.preview_list — a project's live PR/branch preview environments — status, URL, expiry (auto-created via GitHub webhook, no create tool) (free)
  • lavela.preview_destroy — manually tear down a preview environment before its TTL (free)
  • lavela.preview_webhook_setup — generate/rotate the project's GitHub webhook secret + settings for preview environments (shown once) (free)
  • lavela.exec_compute — run a quick command inside a service's running server (≤60s; cmd in /bin/sh, or argv without a shell) — debug / one-line check; it never starts or wakes a server (a stopped one answers MACHINE_NOT_RUNNING), returns up to 64 KiB of each of stdout and stderr (then truncated), is limited to 10 a minute, and on a server with a disk or a database/cache server can change data on the disk, so confirm with the user first (dryRun); lavela never returns a password, though a command run in your server can read its environment (free)
  • lavela.get_logs (core) — recent log lines for a service (debug a deploy / crash) (free)
  • lavela.compute_build_status (core) — progress of a from-repo build (by buildId, or a project's latest build) — with the fix when it failed (free)
  • lavela.compute_rebuild (core) — start a finished build again with exactly its kept settings (branch, folder, size, port, env, mounts) — or with a new port, folder or branch — how a server is redeployed after the user pushes new code, after a lavela-side stop, or once the user fixed what failed or refused it (builds are included (60 a month per server, at least 60 per account; at most 10 a day; with only the welcome credit 20 a month in total, 10 minutes each); the server keeps its size and always-on setting, so its price (a removed one comes back at the size and always-on setting it last had; a database/cache one that would come back sleeping is refused — DATABASE_NEEDS_ALWAYS_ON — never switched to always on silently) — confirm first)
  • lavela.destroy_compute (core) — remove a server: it stops being charged. Its own disk is lost; an attached volume (still billed), its daily snapshots and managed databases stay until you delete them or the project (free — confirm the exact server first)

Data and storage

5 tools
  • lavela.provision_database (core) — managed Postgres (pooling; no lavela backups — the database provider keeps only a short point-in-time history, so take your own dumps); wireToService injects DATABASE_URL; the result states its region and the free limits (NOT currently usage-billed (a per-account limit, a hosted app's own database included) — confirm first)
  • lavela.provision_cache — closed — creates nothing (refused with MANAGED_CACHE_UNAVAILABLE); bring your own REDIS_URL from your own provider (set_compute_secret), or run valkey/redis as your own server (provision_compute); existing ones stay listed and deletable (nothing is created)
  • lavela.provision_volume — persistent disk to self-host a stateful service (e.g. Postgres or Elasticsearch) — attach via provision_compute mounts. Single-node, NOT replicated; its size can't be changed later through lavela. Fly keeps a daily snapshot of each disk for up to 5 days by default; it is not a backup service, and lavela cannot restore it for you. (paid per GB from the wallet — confirm first)
  • lavela.list_resources (core) — a project's managed databases, storage and error tracking + volumes, with ids (free)
  • lavela.destroy_resource — permanently delete a managed resource or volume (data is lost) — a disk is deleted now, or only after the owner approves a link the call returns when the account asks for that; Fly keeps its daily snapshots for their retention (5 days by default), which cannot be restored through lavela, and then deletes them (free — confirm the exact resource first)

Domains, email and payments

9 tools
  • lavela.provision_domain (core) — connect a domain you own (DNS) (free (no purchase))
  • lavela.diagnose_domain (core) — why a domain does not work yet: each DNS record expected vs found, HTTPS, and what to fix at the registrar (free)
  • lavela.provision_email (core) — DKIM/SPF/DMARC for the domain (free)
  • lavela.send_email — send email from the verified domain (free)
  • lavela.connect_stripe (core) — accept payments (starts KYC — confirm first)
  • lavela.create_checkout (core) — a paid checkout link for customers (free — settles to you in full, no lavela fee)
  • lavela.payments_options — ways to collect payments where Stripe won't pay out to the user's country (South Korea first): the options that fit their answers, with fees, settlement and sources — options and conditions, not advice (free)
  • lavela.connect_github (core) — a browser link to connect GitHub, so private repos can be built + deployed (free)
  • lavela.billing_setup_card — the link where the user adds a payment method (wallet page, or a card link on older accounts) — covers lavela's own compute + ad-commission fees, not their sales (free — the user acts in the console)

Status and troubleshooting

18 tools
  • lavela.project_overview (core) — everything about one project in one call — its URLs, each server's state and machine ids, last builds, hosting, domain, email, payments, databases/volumes and the balance (whether it answers: check_health) (free)
  • lavela.get_status (core) — check provisioning status (free)
  • lavela.list_projects (core) — list your projects (free)
  • lavela.delete_project (core) — delete a project for good — its servers, hosting and email domain, and its disks and their snapshots at once (managed databases are kept unless data release is on — delete them first if wanted); refused while an ad campaign is live (free — irreversible; confirm the exact project name first)
  • lavela.archive_project — hide an unused project from list_projects — does NOT stop its servers or their charges (free — confirm which project first)
  • lavela.unarchive_project — restore an archived project with its prior status (free)
  • lavela.compliance_generate — privacy policy + terms (not legal advice) (free)
  • lavela.compliance_list — list generated legal docs (free)
  • lavela.security_scan — scan a repo for dependency vulnerabilities + committed secrets (async) (free)
  • lavela.security_scan_status — poll the most recent scan for its result (free)
  • lavela.list_security_scans — scan history for a project (free)
  • lavela.provision_error_tracking — error tracking + DSN for the app (capture exceptions) (NOT usage-billed, but it counts toward the account's managed-resource limit and needs a paid top-up (refused on the free welcome credit — use the user's own Sentry DSN with set_compute_secret there) — confirm first)
  • lavela.get_errors — recent captured exceptions for a project (needs provision_error_tracking and an app that reports to Sentry; get_logs works without either) (free)
  • lavela.daily_brief — AI summary of recent project activity (free)
  • lavela.check_health (core) — is the live app (web hosting or server) up and serving a real page right now? (free (wakes a sleeping server, billed as awake time))
  • lavela.list_deployments — list a web-hosting site's production deployments (rollback targets; web-hosting sites only) (free)
  • lavela.rollback — instant rollback of a web-hosting site to a previous deployment (web-hosting sites only — a server has no rollback) (free — confirm first)
  • lavela.redeploy (core) — redeploy a web-hosting app from its latest repo (same folder/branch/env as last time) — a server on compute redeploys with compute_rebuild (free)

Advertising tools

12 tools

Launching ads through lavela is not open yet. Drafts, status and reports work; ads_launch and ads_set_budget do not launch anything — at most they record a guided handoff that the user finishes in the ad platform, and a call refused as not open means exactly that; ads_provision_account is closed for now.

  • lavela.ads_platforms — list ad platforms (Google/Meta/TikTok) (free)
  • lavela.ads_draft — draft + save a multi-platform campaign (you write the copy) (free to draft)
  • lavela.ads_launch — record a drafted campaign as a guided handoff that the user finishes in the ad platform (budget confirm gate) — launching ads through lavela is not open yet, so nothing goes live (free — the user pays the ad platform directly)
  • lavela.ads_status — campaign states (free)
  • lavela.ads_pause — pause a campaign (free)
  • lavela.ads_provision_account — create the user's pooled Google Ads or Meta Ads account under lavela's MCC/Business — CLOSED for now: creating a new account is refused while launching ads through lavela is not open yet; an account that already exists is only looked up (free)
  • lavela.ads_assets_push — host an image/video creative at a stable URL + per-platform specs (free)
  • lavela.ads_setup_tracking — mint a conversion write-key + snippet for cross-platform tracking (the basis for ads_report) (free)
  • lavela.ads_report — blended cross-platform spend / CPA / ROAS — the truth no single ad platform gives (free)
  • lavela.ads_conversions — recent recorded conversions per platform (free)
  • lavela.ads_set_budget — record the daily budget of ONE campaign on ONE platform as a guided handoff the user applies in the ad platform; changing the budget of a live campaign through lavela is not open yet (free — the user pays the ad platform directly)
  • lavela.ads_commission — this month's ~10% ad-management fee owed to lavela — ⚠️ metered from Google-API-lane spend ONLY today; handoff campaigns and other platforms aren't captured, so this can UNDER-report (free)

Pricing and payments

Your OWN sales settle to you IN FULL via Stripe Connect (in Stripe-supported countries) — lavela takes 0% of your revenue, is not the merchant of your sales, and charges no per-charge fee and no subscription fee (the ad commission below is the only recurring fee). lavela makes its money on what it runs for you: servers (provision_compute_from_repo / provision_compute, plus one-off jobs, schedules and volumes) are paid from your prepaid lavela wallet — priced by size per server, billed by the second, the same in every region: a server that sleeps when idle pays a base fee while it sleeps (US$2 a month) and its size's always-on rate while it is awake, never more than that rate a month; an always-on server pays that rate (512 MB: US$7 a month always on, US$2–7 sleeping), and after a paid top-up bigger sizes up to 8 GB can be chosen or switched to (up to US$92 a month always on); builds included (up to 60 a month per server and 10 a day, each up to 30 minutes; with only the welcome credit 20 a month in total, each up to 10 minutes, until a paid top-up) — prices: https://console.lavela.dev/pricing; the balance is in lavela.account_status (accounts on the older plan have a card on file instead) — plus, if you run ads through lavela, a commission charged to your card once a month on the ad spend in the ad account lavela set up for you (every campaign in it, including any you run there yourself). When lavela's welcome program is open, an eligible new account gets free compute credit once, automatically after accepting the Terms, no card needed (lavela.account_status says whether it's available and how much — don't promise it otherwise). While on that credit the account runs ONE 512 MB server built from a GitHub repo — every app deploys that way, a Vite/React/Next frontend too (launch_saas's next_step routes it to provision_compute_from_repo) — and can apply its secrets; lavela.account_status says what the credit covers and what is left. Web hosting (provision_hosting), databases, schedules, one-off jobs, volumes, uploads, email, ads and previews need a paid top-up, and a paid top-up lifts every trial limit — until every paid top-up is refunded in full while welcome credit is left: the account is then back on the credit's limits (512 MB included) until its next paid top-up, and a bigger server already running keeps running but must be changed to 512 MB before it is redeployed. Managed Postgres has no usage charge today (free within its provider's free-plan limits, which provision_database's result states; a per-account limit bounds it, a hosted app's own database included) — don't promise the user a fixed price. lavela has no managed Redis: bring your own REDIS_URL (from the user's own provider, set with set_compute_secret), or run valkey or redis as a server of your own (provision_compute: private and always on, not on the welcome credit). Managed object storage (provision_storage) is disabled by default on most deployments (shared-key risk).

New servers run in Tokyo. Server prices do not change with the region; data transfer is priced by the region the traffic leaves from.

View pricing

Good to know

  • lavela never edits your source code — your own coding agent does, with diffs you approve.
  • Connect by adding https://console.lavela.dev/api/mcp to your MCP client and signing in through the browser (no token to paste), or run npx @lavela/cli connect — that connection has the core tools (core: true). For every tool (core: false too — ads, schedules, previews, security scans, legal docs, volumes/storage, jobs, image push) connect with https://console.lavela.dev/api/mcp/all. Every tool runs as the signed-in lavela account. Details: https://console.lavela.dev/docs/mcp
  • A request your connection makes within its permissions is handled as the user's own request. A browser sign-in (and npx @lavela/cli connect) gives every permission except adding funds; a manual token has the permissions the user chose. The user can disconnect an app or revoke a token any time (Connect your agent → Manage connections). lavela itself requires only a few confirmations in an agent's request — the project's exact name to delete a project, the daily budget repeated to launch an ad or change its budget, an explicit flag to delete a hosted app's live database — and only the user can accept the Terms (in the browser), add funds or turn on automatic top-up (in the console). It adds no other confirmation prompt, so confirm everything else with the user yourself.
  • Every result carries a next_step suggesting what to do next.
  • The compute + data tools make lavela a full host: web/API + managed Postgres, persistent volumes, write-only secrets, one-off jobs, recurring cron schedules, PR/branch preview environments (isolated Neon DB branch + Vercel deploy, auto-created/torn-down via GitHub webhook once one is registered on the repo — see preview_list/preview_destroy; preview_webhook_setup returns the per-project webhook settings the user adds in GitHub), a private network between your servers (a server answers at its .internal address only while it runs — nothing wakes a sleeping one there), logs + error tracking, and basic uptime/downtime alerting for web-hosting sites (a 15-minute monitor notifies the project's webhook channels, if any, on a status change; servers on compute are not monitored — check them with check_health) — a small full-stack SaaS runs end-to-end on lavela, minus uptime monitoring of its servers. Not yet in-house: managed Elasticsearch, a full metrics/observability dashboard (CPU/memory/request-rate, custom alert rules — beyond the basic uptime check above), autoscaling, fully automatic preview-webhook registration (the user still adds the webhook in GitHub). Managed object storage (provision_storage) exists but is disabled by default on most deployments — see that tool's own description.
  • A server's own disk is erased on every redeploy, restart and sleep: files an app writes there (a SQLite file, uploads) do not survive. Keep data in a database (lavela.provision_database, or one under the user's own Supabase or Neon account) or on a volume (mounts). Free within these limits per database: 0.5 GB storage, 100 compute-hours a month and 5 GB of data transfer a month (10 branches, previews included). Past the compute or transfer allowance the database pauses until next month; past the storage cap, writes fail. Your data is kept. lavela takes no backups of a database, so keep your own dumps.
  • Nothing watches a server for you: servers are not monitored, and no alert is sent if one goes down. A web-hosting site is checked every 15 minutes, and a change is sent to the project's Slack, Discord or webhook channels (never by email). For a server, run lavela.check_health (it wakes a sleeping server, billed as awake time) and read lavela.get_logs.
  • On the free welcome credit some lanes are closed (web hosting, preview environments, lavela's error tracking and analytics, its databases, email, schedules, one-off jobs, volumes, uploads, ads); a paid top-up of at least the minimum (wallet.topUpMinimum in account_status) opens them, and the refusal a closed lane returns says what to do meanwhile: instead of web hosting, deploy the repo as a server (lavela.provision_compute_from_repo takes every app on the credit); instead of error tracking, a free Sentry project under the user's own account (its DSN set with lavela.set_compute_secret); instead of analytics, the user's own Plausible or Google Analytics snippet; instead of a database, a free Supabase or Neon one (DATABASE_URL, set with lavela.set_compute_secret); instead of lavela's email, the app's own Resend key.

Related pages

About Lavela — lavela