Insights › Builder guides

Cursor app pre-launch audit: what your repo can't tell you

With Cursor you own the code and the repo, so your CI already checks the source — but the deployed URL can serve stale builds, miss headers, leak env vars and fail to index in ways a repo scanner can't see. Here's the deployed-surface checklist.

Aug 8, 2026 · 6 min read

The short version

Cursor gives you full control over your repo, which means your CI already checks linting, types and tests. But the deployed URL is a different machine with different config, and what it serves right now can diverge from what main says it should. The checklist below is the deployed-surface audit: what your repo can't tell you because it's only visible by loading the live URL.

1. The deployed app vs. the committed code

The most common gap in a Cursor-built app: what's on main is correct, but what's serving is stale. A broken env var, a failed deploy, a CDN caching an old build, a route that 404s only in production. Your CI passes; your visitors get an error.

1
Load every public route on the live URL
Not just the homepage — your pricing page, your docs, your auth flow. A route that works in dev can 404 or crash in prod because of an environment-specific module or a missing env var.
2
Check the redirect chain
Does the bare domain redirect to www (or vice versa)? Does HTTP 301 to HTTPS? Does every variant end up at the same canonical URL? A gap in the redirect chain splits your visitors and your ranking signals.
3
Inspect the SSL certificate
An expiring or misconfigured cert is a full-page browser warning that turns visitors away before they see a single pixel. Most hosting platforms auto-renew, but a custom domain with manual DNS can let one lapse.

2. Security headers on the deployment

Your repo might have a next.config.ts or an nginx config that declares security headers, but headers are set by the server that responds to the request — and that's not always the server you configured. A CDN, a reverse proxy, or a platform default can strip or override headers between your config and the wire.

Actuant reads the real response headers from your live deployment and grades each one:

Content-Security-Policy. Is it present? Does it use unsafe-inline and unsafe-eval? Are the script-src origins narrowly scoped?
Strict-Transport-Security. Is max-age at least one year? Is includeSubDomains set?
X-Frame-Options or CSP frame-ancestors. Does anything prevent clickjacking?
X-Content-Type-Options: nosniff. Present on every response?
Referrer-Policy. Set to a safe value, or leaking full URLs on every outbound click?
Permissions-Policy. Restricting camera, mic and geolocation, or leaving them open by default?
Server header. Does the deployment leak its server type and version (Server: nginx/1.25)?

3. Data access: RLS and exposed endpoints

If your app uses Supabase, the Row-Level Security policies on your tables decide whether an unauthenticated request can read your users' data. Your repo might have migration files that enable RLS, but the actual database might not have had those migrations applied — or they were applied and then a teammate disabled RLS to debug and forgot to re-enable it.

Actuant probes the Supabase REST API from outside: it sends an unauthenticated request to each table's endpoint and reports whether rows came back. A pass means RLS is enabled. A fail means your data is publicly readable — which is the highest-severity finding an audit can produce.

4. Crawlability and AI visibility

Even if your app is server-rendered (Next.js, Remix, SvelteKit), the deployed HTML might still be thin: a <title> that's the same on every route, no meta description, no canonical tag, a missing sitemap. These are all one-line fixes that fall through the gap between "the code compiles" and "the page is discoverable."

Also check whether your robots.txt is blocking anything unintentionally. A generated robots.txt that ships with Disallow: / is a total indexing blocker that survives every CI check because it's valid syntax.

5. The fix workflow: PRs you review

Because Cursor users already work in a repo with pull requests, the fixes land the same way: Actuant connects to your GitHub repo, opens a PR with the metadata, security header and config changes, and you review the diff before merging. Nothing changes on your deployment without going through the same review flow as the rest of your code.

The PR is the right unit for these fixes — each change is a specific file edit with a clear explanation of what it fixes and which check it resolves. You can merge them one at a time or all at once.

The checklist as a scorecard

Every item above is a check Actuant runs against your deployed URL. It loads the page in a real browser, reads the response headers, follows the redirect chain, probes for data access, grades the CSP, and scores the result 0–100. The report shows each check as pass, partial or fail with the exact header, tag or config line to fix — and the fixes arrive as pull requests in your repo.

Keep reading

Content-Security-Policy: what it protects, how to write one, and the mistake that makes it useless

A Content-Security-Policy tells the browser which scripts, styles and connections to trust — it's your primary defense against XSS. A generated app ships with none. Here's how to write one that's strong enough to matter and test it without breaking anything.

Canonical tags: the rules that actually matter

A canonical tag tells Google which URL is the real one when a page is reachable at several addresses. Get it wrong and you split your ranking signals or deindex the wrong page. Here are the seven rules, and how generated apps break them.

Security headers: the six your app needs and what each one protects

Security headers are HTTP response headers that tell the browser how to defend your visitors. A generated deploy sets none of them. Here are the six that matter, what each one does, and how to check they're actually being served.