How can we help?

Builds enter the queue when the cluster is at capacity. Open the project, expand the build row, and you'll see your queue position and estimated wait time. Most queue holds clear in under 90 seconds. If a build is queued for longer than 10 minutes, hit cancel and email support with the project name — it usually means an upstream webhook delivery was lost and we need to nudge it.

Open the deployment row from the project's Deploys tab. The log streams live during the build and is permanently archived once the build finishes. The log is split into stages (clone → install → build → start). The first red line in the log is almost always the actual failure — the rest are downstream consequences.

On the project's Deployments tab, find the last Ready deploy you trust and click Rollback. We re-deploy the production application pinned to that commit and stream the rollback's progress on the same SSE feed as a push deploy — status pill, live log lines, email-on-finish, working Cancel button. The previous green container keeps serving traffic until the rollback's new container passes its healthcheck, so the live URL never sees a gap. For the full playbook (when to use rollback vs promote, how to configure auto-rollback, what each primitive costs in build minutes) read the rollback & promote playbook.

PR Previews are available on Student, Pro and Enterprise plans. If your team is on Free, the toggle is hidden and pushes to a PR head branch are tracked as Skipped in the Deployments tab while production auto-deploy keeps working normally. On paid plans, head to Project → Settings → Engine and confirm PR Previewsis turned on. If it is and the PR still didn't open a preview, check that the Launchverse GitHub App is installed on the repo with read access; preview builds rely on the same installation as production deploys. Background: PR preview deployments on Launchverse.

Open the project's Previewstab, find the preview row for the PR you've signed off on, and click Promote to production. We capture the exact commit SHA the preview was last built against and re-deploy your production application pinned to it — no rebuild loop, no copying env vars, no manual git push. Force-pushing the PR branch after promotion does not silently change what is in production; the SHA is captured at promote time. The promotion streams on the same SSE feed as a push deploy with a working Cancel button throughout.

After every successful deploy we run a 60-second HTTP health probe against your live URL. Three or more samples returning HTTP ≥ 500 (or timeout) trigger an automatic rollback to the previous green commit plus a deploy-failed email and a Failed commit status posted back to GitHub. Three opt-outs short-circuit the probe: the project owner flipped auto_rollback_enabled to off; the project is inside a 30-minute cooldown from the last auto-rollback; or there is no previous green commit to roll back to. Configure the probe path (default /) on the project's Settings tab — a real /healthzendpoint that checks your database and Redis is much better than the default homepage probe. Full playbook: Rollback & promote on Launchverse.

That's the default — previews share the parent project's environment variables, including DATABASE_URL. Two safe ways to break the link: (1) pass a READ_ONLY=true var scoped only to the preview environment and have your application skip writes when set, or (2) provision a second managed database on the same project and override DATABASE_URL on the preview environment so it points at the second database instead of production. Pattern (2) is the right answer for migration-heavy PRs. Both patterns are walked through in PR preview deployments on Launchverse.

Click Cancelon any build row that's in a non-terminal state (Queued, Building, Provisioning, Deploying). The container is stopped, the build slot is released to the pool, and the deploy is marked Canceled. You aren't billed for the partial build minutes.

Go to Project → Domains and add the domain. We give you the exact DNS record to create (CNAME for subdomains, A record for apex). Save it at your registrar, then click Verify. Verification usually completes in under a minute; certificates are issued automatically right after.

For root domains like example.com (without www.), most registrars want an A record. Set it to the IP shown on the Domains page. If your registrar supports ALIAS or flattened CNAMEat the apex, those work too — same target.

We don't hold registrations — you keep the domain at your registrar. To move traffic to a Launchverse-hosted app, just point the relevant A or CNAME record at the value shown on the Domains page. Email support if you need help coordinating a low-downtime cutover for a live site.

99% of cert issuance failures are DNS-related — the domain isn't pointed at us yet, or there's a stale AAAA / CAA record blocking issuance. On the Domains page, click Re-verify. If it still fails after DNS has propagated, send us the domain — we have operator tooling to surface the exact rejection reason.

BYOS (Bring Your Own Server) lets you run Launchverse-managed deployments on a server you control. From the dashboard, add the host's IP and the SSH public key we generate for it, then run the one-line bootstrap command on the server. We validate connectivity, install the runtime, and surface the host on your servers list. Use Hetzner CCX13 or larger for production; the smallest tier is fine for previews.

OOM-kill events typically come from a build trying to allocate more memory than the server has free. Two fixes: (1) bump the server tier, or (2) add a swap file (see below). The dashboard's server metrics page shows OOM events in red — if you see clustering, your build needs more memory than the host can provide.

On Ubuntu / Debian: sudo fallocate -l 2G /swapfile && sudo chmod 600 /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile. Add /swapfile none swap sw 0 0 to /etc/fstab to make it persist across reboots. 2 GB of swap is enough for most builds.

Open Dashboard → SSH Keys, click Rotateon the affected key, and we'll generate a fresh keypair and push the new public key to every BYOS host that uses it. The old private key is revoked immediately.

On the sign-in page, click Forgot password and enter your email. We send a recovery link that expires in 60 minutes. If the email never arrives, check spam; if it's definitely not there, email support from the address on the account.

If GitHub kicks you back to Launchverse without signing you in, the most common cause is browser-extension interference (uBlock, Privacy Badger). Try a clean Chrome / Firefox window in incognito mode. If that works, allow launchverse.app in your blocker. If it still fails, email support with the error code shown on the redirect.

Go to Dashboard → API Tokens, click New token, give it a name and the scopes you need (read / write / deploy), and copy the value. Tokens are shown once and start with lvse_. If you lose one, revoke and mint a new one — we cannot recover the plaintext.

Go to Dashboard → API Tokens, find the token by name or by its 4-character suffix, and click Revoke. The token is invalidated immediately across every region. If the leak is in a public Git history, rotate the token first, then rewrite the history with git filter-repo.

On the Pricing page or Dashboard → Billing, click the plan you want. Upgrades take effect immediately and the new quota is prorated for the rest of the billing month. Downgrades take effect at the end of the current period — you keep the higher plan's benefits until then.

Cancelling stops auto-renewal at period end — it doesn't refund a charge that's already gone through. If a charge happened afteryou cancelled, that's on us. Email billing@launchverse.app with the transaction reference and we'll refund within 2 business days.

Open Dashboard → Billing, find the period you need, and click Download invoice. Invoices include your team name, address, VAT number (if configured), and a Naira-denominated breakdown. To set the billing entity, edit it on the Billing page first.

Build minutes are charged from the moment your build actually starts — queue time is free. If a build is rebuilt by the system (e.g. because the host webhook didn't confirm), the second attempt is on us, not you. The Usage page reconciles within an hour of every build.

Open the project, then the Resources tab. Each resource card has a Revealtoggle that surfaces the username, password, database name, internal connection URL, and (when public access is on) the external URL and public port. For marketplace services we also surface the generated env variables that look like credentials — tokens, API keys, admin passwords. Credentials are fetched server-side from the engine on every load, so a refresh always shows the current secret rather than a stale post-provision flash. Lifecycle controls (start, stop, restart, delete) are at the bottom of each card. Read more in our guide: Provision a managed Postgres database.

Cron jobs live both on the project's Overview tab and on the global Dashboard → Cron Jobs page. Click the pencil icon next to any job to change its name, cron expression, or command — the change propagates to the engine immediately. Deletion unschedules the engine task and removes the local row in one step; there is no recovery, so confirm carefully. Per-project lists make audits easier than the global view; both are powered by the same data. Cron syntax cheatsheet and pitfalls are in the Schedule cron jobs guide.

Open a project and switch to the Observabilitytab. The KPI strip at the top shows real deploy counts, success rate, build minutes, and the engine's container status. The Sentinel panel below renders live CPU and memory usage as a 30-minute moving window when the platform's sentinel agent is enabled on your underlying server — if it isn't available, we say so honestly rather than show synthetic data. The deploy reliability chart and recent deploys list are always available regardless. Refreshes every 60 seconds. More background: Production observability without Datadog.

If your application's outbound calls fail with getaddrinfo ENOTFOUNDor connection refused, the most likely cause is the project's egress allowlist on the Securitytab. The allowlist names every host your container is permitted to reach — everything else is dropped. Add the missing hostname (e.g. api.stripe.com) and redeploy. Wildcards are supported so *.s3.amazonaws.comcovers every bucket. Internal services on the same project (Postgres, Redis) are always reachable and don't need to be in the allowlist. Background reading: Web App Firewall, HTTPS, and egress allowlists explained.