Navigating the Launchverse Dashboard: An Operator's Tour

The Launchverse dashboard is intentionally a small handful of tabs rather than a sprawling tree of nested settings — but if you're new to the platform it's not always obvious where a given setting lives. This is a complete tour of a project's tabs, what each one is actually responsible for, and the one thing on each tab that operators forget exists.

Where you start: the top-level dashboard

Hitting /dashboard after login lands you on the team-level overview. The four things here:

• Plan & usage tile. Shows your current plan tier, build minutes consumed this billing period, and two distinct dates: when your monthly usage resets (anniversary day of the month) and when your plan expires (either your subscription's renewal date or your coupon's expiry, surfaced as Coupon expires on … when applicable).
• Recent deployments feed. A team-wide rollup of the last ~20 deploys across every project. Click a row to jump straight to that project's Deployments tab.
• Projects grid. Every project the team owns, with status pill and "Open" button.
• The onboarding tour. A four-step walkthrough that runs once for brand-new users. If you missed it, the help icon in the top bar lets you re-trigger it.

The team switcher in the top-left lets owners and members move between every team they belong to. The active team scopes everything on the page including the usage tile and the projects grid.

Inside a project: the tabs

Overview

Live state of the production deployment in one glance:

• The current live URL, status, and last deploy timestamp.
• A "Deploy now" button (manual redeploy of the trigger branch).
• The four most recent deploys with status pills, branch, and commit message.
• A project-scoped cron-jobs section if any are configured.

The one thing operators forget: the latest-deployment card is scoped to production deploys only. A closed PR's commit will not appear here even if it was the most recent build in the engine.

Deployments

The audit log for every build the engine has ever performed against the production application. Each row carries:

• Status (Deploying, Ready, Failed, Canceled, …).
• Trigger (push, manual redeploy, rollback, promote, env-var-triggered rebuild, external hook).
• Branch + commit hash + commit message.
• Build-started / build-finished timestamps + the resulting build minutes.
• A Rollback button on any successful past deploy.
• A Cancel button on any in-flight build, regardless of which trigger started it.

Click a row to expand the full build log, which streams live during the build and is archived once it terminates. The log is split into stages (clone → install → build → start) so you can jump to the failure without scrolling.

The one thing operators forget: the AI-Explain panel on every failed deploy. Failed-deploy rows surface a one-click "Explain this failure" button that summarises the first red line in the log and proposes a fix as a PR against the offending repo. The PR path requires the Launchverse GitHub App to be installed on the repo with write scope on contents.

Previews

The PR preview environments tab. One row per non-deleted preview, with:

• The preview URL (click to open in a new tab).
• Lifecycle status (creating, active, closing, failed).
• The PR number and head commit.
• A Promote to production button that re-deploys the preview's commit against the project's main application.
• A Delete button that tears down the preview immediately (skipping the 24-hour grace window).

If PR Previews are paused on your plan tier, this tab still renders but every row is marked Skipped and the toggle in Settings → Engine reads Coming Soon.

Resources

Everything the project provisions that isn't the application itself:

• Managed databases (Postgres, MySQL, MariaDB, MongoDB, Clickhouse, Redis).
• Marketplace services (n8n, WordPress, Ghost, Strapi, etc.).
• The credentials, internal URL, external URL, and public port for each, exposed as copyable fields without forcing you to scroll through the post-provision toast.

The one thing operators forget: every resource has an internal URL that other containers in the same project network reach by name (no public traversal) and an external URL that's reachable from outside the network. Use the internal URL in your application's DATABASE_URL / REDIS_URL env vars; use the external URL only when you're connecting from your laptop.

Domains

Custom domains attached to this project. For each, the page surfaces:

• The exact DNS record to add. Subdomains get CNAME; apex domains get an A record (or ALIAS / flattened CNAME on registrars that support it).
• A Verify button that re-checks DNS and issues a TLS certificate as soon as it resolves.
• The domain's TLS status (provisioning, issued, renewing, error) with the actual ACME error message inline when one's stuck.

The one thing operators forget: if you previously verified the same domain on a different Launchverse account, you can claim it back with a one-time _launchverse-verify TXT record. The previous account is emailed the moment the transfer lands so the handover is transparent on both sides.

Environment

Environment variables for the project, scoped per environment (production, preview).

• Variables on the production environment apply to push deploys and rollbacks.
• Variables on the preview environment apply to PR-preview builds. Variables defined only on the preview environment do not leak to production.
• Changing a variable triggers an auto-redeploy of the affected environment, which now lands as a real Deployments row with live logs, status, cancel, and email-on-finish.

The one thing operators forget: variables marked secret are masked everywhere in the UI but are still available to the running container in plain text. Rotate them like any other credential.

Observability

Real telemetry, not synthetic graphs. The tab shows:

• Deploy success rate — last 30 days, with the drop-off visible at a glance.
• Build minutes — cumulative this billing period, with a top-5-by-minute project breakdown if you're looking at the team-level view.
• Container status — live state pulled from the engine on every page load.
• Reliability histogram — 30-day binned deploy outcomes (Ready, Failed, Canceled).
• CPU / memory time-series — rendered when the platform's optional metrics agent is enabled; otherwise the tab says so honestly rather than drawing fake graphs.

Security

The platform's per-project security configuration in one place:

• HTTPS enforcement — redirect all http:// traffic to https:// at the proxy.
• Basic-auth gate — front your application with a username/password challenge (useful for staging-like environments).
• Egress allowlist — name every external hostname your container is permitted to call. Requests to anything not on the list are dropped at the platform's egress proxy.

The one thing operators forget: the egress allowlist defaults to "permit all" on Free / Student and "deny by default" on Pro / Enterprise. If your production container is suddenly unable to reach an outbound API after you upgrade, the allowlist is the first place to look.

Settings

Project metadata and the Engine sub-page. The most-touched fields:

• Trigger branch — which branch auto-deploys to production on push.
• PR Previews toggle — turn the per-PR preview environments on or off.
• Auto-rollback — enable / disable + custom health-probe path. See the rollback playbook for the configuration that makes auto-rollback do its job without false positives.
• Resource sizing — CPU and memory limits per container.
• Delete project — the only place the destructive action lives. Project deletion now reports a truthful result (partial-success when an underlying resource can't be cleaned up immediately, with a follow-up action) rather than always saying "Deleted successfully".

Quick reference

The two tabs people forget exist: Resources (because the credentials are inside it, not on the deploy wizard) and Observability (because the deploy-success-rate is the single best indicator of whether your CI/CD pipeline is healthy and almost no-one looks at it until something breaks).