ZipLoom Documentation

The complete platform — what every feature does and how to use it, verified against the codebase. This is the source for docs.ziploom.dev.

Pick a page from the left; use the filter to narrow by area.

Getting Started

What it is. The path from zero to a first scanned, live deploy — sign up, connect GitHub, pick a repo, deploy.

Why it matters. ZipLoom sits between your repository and your host: it scans AI-generated code and gates the deploy, so nothing risky reaches production. Everything runs at **a flat subscription with no usage meters (monthly, or annual at a discount).

Walkthrough

Go to https://app.ziploom.dev and sign up with email or Google.
(Recommended) Enable two-factor authentication (TOTP). Once on, 2FA is required on every sign-in — before any code scan runs.
Complete onboarding: connect your GitHub account and grant access to the repositories you want to deploy.
Connect at least one deploy target (Settings → Deploy Targets) — Vercel, Netlify, Cloudflare Pages, Railway, Render, Google Cloud Run, AWS, DigitalOcean, Vultr, or Contabo — 10 in total. The accounts stay yours.
Create a Project from a connected repo. ZipLoom auto-detects the framework.
Trigger a Deployment. The security + compatibility scan runs first; a clean result deploys, a Critical finding blocks it with fix guidance.

Options & settings

Workspace — everything (projects, deploys, team, billing) is scoped to your workspace; switch workspaces from the top-left switcher.
Roles — Owner / Admin / Member (Settings → Team).

Edge cases & gotchas

No deploy target connected → deploys can't run. Connect one first.
GitHub access not granted to a repo → it won't appear when creating a project.
2FA is optional to enable but, once enabled, cannot be skipped at sign-in.

Projects

What it is. A Project is a connected repository ZipLoom manages and deploys. The Projects page (/projects) lists all applications in this workspace with their framework, target platform, and last-updated time.

Why it matters. Projects are the unit everything else hangs off — deployments, scans, rollouts, and monitoring all belong to a project.

Walkthrough

Open Projects in the sidebar.
Use Filter projects… to find one by name.
Each row shows: project name, Framework (auto-detected), Platform (the connected deploy target), and Updated. Badges indicate GitHub connected and the target (e.g. Vercel, Netlify, Railway) and offer Open live URL.
Create a new project with New Project (/projects/new) → choose a connected repo → ZipLoom detects the framework and prepares it for deployment.
Click a project to open its detail view (/projects/[id]) for its deployments and settings.

Options & settings

Framework auto-detection — set automatically from the repo; drives the build configuration.
Platform — the deploy target bound to the project (managed under Deploy Targets).

Edge cases & gotchas

A repo must be GitHub-connected and accessible to appear as a project source.
"Open live URL" appears only after a successful deploy has produced a URL.

Deploy Targets

What it is. The platform accounts ZipLoom deploys into — "Connect the platform accounts ZipLoom deploys into. They stay yours." Managed at Settings → Deploy Targets (/settings/deploy-targets).

Why it matters. ZipLoom doesn't host your app; it deploys to your provider accounts. You keep ownership and can leave at any time (see Self-Host Export).

Supported targets

AWS · Cloudflare Pages · Contabo · DigitalOcean · Google Cloud Run · Netlify · Railway · Render · Vercel · Vultr — 10 platforms, zero config (framework auto-detected, scanned first).

Verified against the adapter factory in packages/deployment-engine/src/platforms/base.ts on 2026-09-22. The deployment_platform database enum also carries amazon_lightsail, which has no adapter — it is not a supported target.

Note: Netlify here is a customer deploy target — where your app can be deployed. It is separate from ZipLoom's own hosting.

Walkthrough

Go to Settings → Deploy Targets.
Find the platform (e.g. Vercel) and click Connect; authorize with that provider. The credentials/account stay yours.
Click Verify to confirm ZipLoom can reach the account.
Bind a target to a project when you create or configure it.
To remove one, click Disconnect — existing live deployments are unaffected; new deploys to that target stop.

Options & settings

Connect / Verify / Disconnect per platform.
AWS (BYOC) — bring-your-own-cloud AWS is configured separately under Settings → AWS.

Edge cases & gotchas

Verify before your first deploy — an unverified/expired connection fails the deploy at the push step.
Disconnecting a target used by a project will block that project's future deploys until re-connected or re-pointed.

Deploying a Project

What it is. Running a build+deploy of a project to its connected target. The Deployments page (/deployments) shows "every deploy across your projects, newest first," and is where you trigger, watch, and manage them.

Why it matters. This is where the scan gate does its job: the security + compatibility checks run before the app is reachable, so risky AI-generated code is blocked, not shipped.

Walkthrough

Open Deployments in the sidebar (or a project's detail page).
Start a deploy with Redeploy — re-run this project (or the deploy action on a new project). ZipLoom pulls the latest commit, auto-detects the framework, and runs the pre-deploy scan.
Watch status in the list. Each deployment row shows Project · Branch / commit · Platform · Duration and a status: - In flight — building/scanning/deploying now. - Ready — live and serving. - Failed — stopped (build error or a blocking security finding). - Cancelled — stopped by a user.
On a Failed build, open it to see the cause — ZipLoom's AI Build Failure Diagnosis names the actual reason in plain English and gives the fix.
On Ready, use the project's Open live URL to view it.

Options & settings

Status filter — All / Ready / In flight / Failed / Cancelled.
Redeploy this project — re-run the latest commit.
Delete deployment — remove a single deployment record.
Clear failed — bulk-remove failed deployments to tidy the list.

Edge cases & gotchas

Critical security findings block the deploy by default — resolve or dismiss them (Security → Findings) to proceed.
"No deployments yet" shows until a project's first deploy.
A failed deploy leaves the previous Ready release serving (nothing is torn down on failure); combine with Auto-Rollback for regressions that pass build but break at runtime.

AI Builder / AI Assistant

What it is. A conversational builder (/ai, "AI assistant") that takes an idea in plain language and moves it toward a deployable project. Prompt: "Describe what you want to build…".

Why it matters. It's the front door for starting something new without hand-wiring a repo — describe it, refine it, and compose it into a deploy.

Walkthrough

Open AI builder in the sidebar.
In the composer, describe what you want to build.
ZipLoom ideates a plan/approach. From there use the action buttons: - ▶️ Continue — proceed with the current direction. - ✏️ Refine idea — adjust scope/requirements and regenerate. - 📋 Use a template — start from a matching template instead. - 🚀 Compose & deploy — turn the result into a project and send it into the deploy flow.
Composing hands off to the normal Projects → Deployments path (scan gate included).

Options & settings

Iterative chat: refine as many times as needed before composing.
Template hand-off connects to the Templates catalog.

Edge cases & gotchas

Output is AI-generated — it still passes the same security scan on deploy; nothing skips the gate because it came from the builder.
Multi-repo composition (AI Stack Composer) is surfaced here and in Discover; deeper multi-repo composition is still rolling out (see Discover's "coming soon" note).

Templates

What it is. A catalog of starting points (/templates) you can launch straight into a project.

Why it matters. Fastest path to a working, deployable app — skip scaffolding and go straight to the scanned deploy flow.

Walkthrough

Open Templates in the sidebar.
Search templates… to filter the catalog.
Pick one and launch it — ZipLoom creates a project from the template's repo (launch from repo) and takes you into the deploy flow.
Popularity/usage is tracked, so commonly-used templates surface.

Options & settings

Search/filter by keyword. ("No templates match your search. Try a broader term." if nothing matches.)

Edge cases & gotchas

A launched template becomes a normal Project — it deploys through the same scan gate.

Discover

What it is. Open-source discovery (/discover) — "Search open source, then launch it live in one click."

Why it matters. Find an existing open-source repo and deploy it through ZipLoom (scanned) without leaving the platform.

Walkthrough

Open Discover in the sidebar.
Search repos… for an open-source project.
Launch a result — ZipLoom creates a project from it (launch from repo) and runs the deploy flow.

Options & settings

Keyword search across open-source repos. ("No repos found. Try a different search." if empty.)

Edge cases & gotchas

Multi-repo AI composition is coming soon — composing several discovered repos into one deployable stack (AI Stack Composer) is still rolling out; single-repo launch works today.
A launched repo is third-party code — the pre-deploy scan applies, so review findings before shipping.

Multi-Platform Deployment

What it is. One project, ten deploy targets. ZipLoom detects your framework, builds the app, runs the security gate, and ships it to the platform you choose — Vercel, Netlify, Cloudflare Pages, Railway, Render, Google Cloud Run, AWS, DigitalOcean, Vultr, or Contabo. The platform accounts stay yours; ZipLoom holds the credentials in the encrypted Secrets Vault and deploys on your behalf.

Why it matters. Most failed launches aren't code failures, they're configuration failures: the wrong build command, a missing environment variable, a runtime mismatch. Handling that once, centrally, means moving between platforms is a redeploy rather than a rewrite — and it's why leaving ZipLoom doesn't strand your app, because it was never hosted here in the first place.

Walkthrough

Connect a platform under Settings → Deploy Targets (see Deploy Targets for the per-platform credential each one needs).
Open a project and choose Deploy. Pick the connected target.
ZipLoom auto-detects the framework and derives the build command, output directory, and runtime. Override any of it if your project is unusual.
Environment variables are pulled from the Secrets Vault at deploy time — decrypted only for that deploy, never stored in plaintext.
The security gate runs. Critical and high findings stop the deploy; lower-severity findings are reported and the release proceeds.
On success you get a live URL. The deployment record keeps the logs, the findings, and the commit it shipped.

Options & settings

Target — which connected platform receives this deploy.
Build overrides — build command, output directory, runtime version, when auto-detection guesses wrong.
Environment variables — per project and per environment, resolved from the vault.
Custom domain — attach your own hostname (see Deploy Targets); certificates are issued and then monitored.
Staged / canary rollout — release gradually instead of cutting over at once (see Operate).

Edge cases & gotchas

Platforms differ in what they can host. A static site, a server-rendered app, and a long-running worker are not interchangeable; the composer picks a sensible target but a Node worker won't run on a static host.
Credentials are per platform. Each target needs its own token or key, and a revoked token fails the deploy rather than silently falling back.
A gated deploy is a stopped deploy, not a broken one. Fix the finding (or disposition it deliberately) and redeploy.
amazon_lightsail appears in the database enum but has no adapter — it is not a supported target. The authoritative list is the adapter factory in packages/deployment-engine/src/platforms/base.ts.
Deployed apps stay live if you cancel. They run in your accounts. You lose scanning, monitoring, and self-healing — not the app.

Security Scanning (Pre-Deploy)

What it is. Every project is scanned before it can deploy. The Security page (/security, "Pre-Deploy Security") runs five checks against a GitHub repo, returning findings graded Critical / High / Medium / Info, each with What this means and How to fix.

Why it matters. AI-generated code routinely ships RLS gaps, leaked secrets, vulnerable dependencies, and misconfigured auth. The scan gate blocks a deploy on Critical findings — before the app is reachable.

The five checks (tabs)

Tab	Checks	Run it	All-clear
Code	Source scan — RLS gaps, secret patterns, injection, auth misconfig	Paste GitHub URL → Scan Code	"No security issues detected…"
CVEs	Dependencies vs. National Vulnerability Database	→ Audit Dependencies	"No known CVEs…"
Health	Repo health score	→ Score Health	—
Licenses	Restricted/copyleft (GPL, AGPL)	→ Scan Licenses	"No restricted or review licenses found."
Env Parity	Drift across `.env`, `.env.staging`, `.env.production`	→ Check Env Parity	"All environment files are in parity."

Walkthrough

Open Security. 2. Pick a tab. 3. Paste a GitHub URL, click the action. 4. Read findings by severity; each shows the risk and the fix. 5. Triage with Finding Memory (Findings page) so it won't re-flag.

Options & settings

Severity summary (Critical/High/Medium/Info) across the top; per-tab actions listed above.

Edge cases & gotchas

ZipLoom needs repo access (connect GitHub first).
Critical findings block the deploy by default.
Env Parity flags a var present in one file but missing in another.

Findings & Finding Memory

What it is. The inbox (/security/findings) collecting every finding across scans, and the Finding Memory system that lets you triage each once.

Why it matters. Without memory, the same issue re-flags every scan. Triage once and the Brain remembers your decision.

Walkthrough

Open Findings. 2. Review by severity (Critical/High/Medium/Info). 3. For each, choose a disposition: accept, dismiss, or fix. 4. Once dispositioned, the Brain stops surfacing it on future scans unless it changes/recurs.

Options & settings

Dispositions: Accept / Dismiss / Fix.
Recurrence Radar surfaces what keeps coming back or regressed after a fix (see Operate).

Edge cases & gotchas

A dismissed finding can reappear if the underlying code changes (that's Recurrence Radar working).
Critical findings still gate deploys until resolved or explicitly dispositioned.

Secrets Vault (AES-256-GCM)

What it is. Encrypted storage for environment variables — "encrypted at rest, decrypted only at deploy time, never in logs." AES-256-GCM.

Why it matters. Env vars hold your keys; leaking them in logs or the repo is a top breach cause. The vault keeps them encrypted and injects them only at deploy.

Walkthrough

Add environment variables to a project's vault. 2. They're encrypted at rest immediately. 3. At deploy time they're decrypted and injected into the build/runtime. 4. They never appear in build logs or the UI in plaintext. - Separately, Secrets Detection scans your code on every push for keys/tokens your AI tool left inline (see its page).

Options & settings

Per-project variables; flag a value for rotation.

Edge cases & gotchas

A secret committed to the repo is caught by Secrets Detection, not the vault — move it into the vault and rotate it.

Secrets Detection

What it is. A scan on every push that flags API keys and tokens left inline in code.

Why it matters. AI coding tools frequently hardcode secrets. Catching them on push stops them reaching a deploy or a public repo.

Walkthrough

On every push (and in the Code scan), ZipLoom scans all files for secret patterns. 2. Matches surface as findings with the file/location. 3. Remove the secret from code, move it to the Secrets Vault, and rotate the exposed credential.

Edge cases & gotchas

Rotate any exposed key even after removing it — assume it's compromised once committed.

Vulnerable Dependency & License Audit

What it is. Two dependency checks: CVE audit (every dependency vs. the National Vulnerability Database, Critical/High flagged) and License Compliance Guard (flags GPL, AGPL, and other copyleft before they can force your source open).

Why it matters. AI-picked dependencies can be vulnerable or carry viral licenses. Both are caught pre-deploy.

Walkthrough

In Security → CVEs, paste the repo → Audit Dependencies. Vulnerable packages list by severity (Critical/High/Medium/Unknown). 2. In Security → Licenses, → Scan Licenses; restricted/review licenses are flagged.

Edge cases & gotchas

"No known CVEs…" / "No restricted or review licenses found." mean clean.
New CVEs appear over time — re-audit periodically, not just at first deploy.

Auth Audit & Lockdown (RLS) Check

What it is. Two configuration checks in the Code scan: the Lockdown Check for Row-Level Security (the missing-RLS class behind CVE-2025-48757) and the Auth Configuration Audit (JWT expiry, CORS policy, session rotation — the class behind the Moltbook breach).

Why it matters. These are the misconfigurations that expose data even when the app "works." They fire before build.

Walkthrough

Run Security → Scan Code. 2. RLS gaps and auth misconfigurations appear as findings with What this means + How to fix. 3. Fix and re-scan; a Critical RLS/auth finding blocks the deploy.

Edge cases & gotchas

The RLS check specifically looks for the absence of row-level security on your data layer — the exact gap that caused CVE-2025-48757.

GitHub Actions Integration & Compliance Mapping

What it is. Two ways security extends beyond the deploy: ziploom/scan-action gates every merge in your CI pipeline, and Compliance Readiness Mapping maps SOC 2, HIPAA, and GDPR controls to your deploy with a PDF export.

Why it matters. Security belongs in the pipeline, not just at deploy — and buyers/auditors ask for compliance evidence.

Walkthrough

GitHub Actions: add ziploom/scan-action to your workflow; it runs the same checks on every PR/merge and can fail the check on findings. Compliance: open Compliance (/compliance), review the mapped controls (SOC 2 / HIPAA / GDPR) against your deploy, and export the PDF.

Edge cases & gotchas

The Action mirrors the platform's scan rules (Governed Safety Rules), so pipeline and deploy stay consistent.
Compliance mapping is a readiness aid, not a certification.

Staged / Canary Rollout

What it is. Gradual traffic shifting across rings — Canary → Early ring → Half traffic → Full deploy (1% → 10% → 50% → 100%) — with an automatic error gate between rings. Managed at /rollout.

Why it matters. A bad release reaches 1% of users, not 100%. If the error gate trips, the rollout stops before wider exposure.

Walkthrough

Start a staged rollout from any deployment detail page (not the rollout list itself — the /rollout page shows history/active rollouts).
The rollout advances through rings; status shows Pending / In progress / Paused / Complete / Rolled back.
Controls: advance (promote to the next ring), pause, resume, rollback.
The error gate auto-pauses/rolls back a ring that breaches the threshold.

Options & settings

Rings: Canary, Early ring, Half traffic, Full deploy.
Manual pause/resume/advance override the automatic progression.

Edge cases & gotchas

Rollouts are started per-deployment; there's no "start" button on the rollout list — go to the deployment.
"No active rollouts." means nothing is mid-rollout.

Auto-Rollback

What it is. A watch on live deploys that automatically restores the last good release when a deploy regresses. Page: /rollback (Active Deploy Watches, Rollback History, Rollbacks Triggered). Business+ tier.

Why it matters. Catches regressions that pass the build but break at runtime — without you watching dashboards.

Walkthrough

Open Auto-rollback. Active watches show status: Watching / Rolled back / Disabled / Expired.
A watch monitors a live deploy against the Default Threshold.
On breach, ZipLoom automatically restores the previous good deploy and records it in Rollback History.

Options & settings

Default Threshold — the error level that triggers a rollback.
Per-deploy policies (rollback.getPolicies).

Edge cases & gotchas

Business+ feature — gated below that tier.
Watches Expire after their window; a Disabled watch won't act.
Complements Self-Healing Deploys (uptime restore) and Staged Rollout (pre-100% gating).

Self-Healing Deploys

What it is. A health check every 15 minutes; if the site goes dark, the last good deploy is restored automatically.

Why it matters. Downtime gets fixed before you (or your users) notice, without manual intervention.

Walkthrough

Once a project is live, ZipLoom probes it on a 15-minute cadence. 2. If a probe finds the site down, it automatically restores the last known-good deploy. 3. The action is logged.

Edge cases & gotchas

This restores availability (site dark); Auto-Rollback handles regressions (error-rate breaches) — they're complementary.

Synthetic Monitoring

What it is. Scheduled smoke-test checks against your live endpoints (/monitor), so you hear about downtime first. Metrics: Pass rate, Runs (30d), Failed runs. Business+ tier.

Why it matters. Proactive uptime/health signal instead of waiting for user reports.

Walkthrough

Open Monitor and complete any Setup required step. 2. Checks run on a schedule; you can also trigger a check manually. 3. Each run shows Pass / Fail / Skipped / Running; open a run for detail. 4. Review the 30-day pass rate and failed-run trend.

Options & settings

Manual trigger check; scheduled runs; per-run detail.

Edge cases & gotchas

Business+ feature ("Upgrade to Business" / "See plans" when gated).
"No check results yet." / "No smoke test runs yet." until the first run.

Performance Budget (Lighthouse CI)

What it is. Lighthouse audits run automatically after each production deploy (/perf), scored across Performance · Accessibility · Best Practices · SEO, checked against budgets.

Why it matters. Performance/accessibility regressions become visible before users report them.

Walkthrough

Deploy to production — the Lighthouse audit runs automatically afterward. 2. Open Perf budget, select a project to view its history. 3. Each deploy shows "All budgets passed" or "Budget exceeded on this deploy" across the four categories.

Options & settings

Budgets per category (Performance/Accessibility/Best Practices/SEO); default budget provided.
Per-project performance history.

Edge cases & gotchas

"No Lighthouse audits recorded yet." until a production deploy runs. Audits are production-deploy-triggered, not on every preview.

Change Impact

What it is. Analyze a dependency update before you take it (/impact): Semver Risk, Dependency Blast Radius, Migration Notes, and Changelog summary. Business+ tier.

Why it matters. Tells you how risky a package bump is — and what it'll touch — before it breaks a build.

Walkthrough

Open Change impact. 2. Enter a package update → Analyze Update. 3. Read the report: Semver Risk (Low/Medium/High/Critical, e.g. "Major — breaking changes likely"), Dependency Blast Radius (what else it affects), Migration Notes, and the Changelog. 4. Past analyses are kept under Recent Analyses.

Edge cases & gotchas

Business+ feature.
"No analyses yet. Enter a package update above." until you run one.

Live Posture Scan (Headers · TLS · DNS)

What it is. External checks against your running URL — not the code, the live site. Covers four areas: Security Header Audit (HSTS, CSP, cookie flags, WAF fingerprint — graded), TLS & Certificate Monitoring (cipher grade, cert expiry, OCSP, HSTS-preload), DNS / Email Auth & Takeover Guard (DNSSEC, CAA, SPF/DKIM/DMARC, and dangling records that let someone claim your subdomain).

Why it matters. Code can be clean while the deployed surface is exposed — an expired cert, a missing header, a takeover-able subdomain.

Walkthrough

After deploy, the live posture checks run against the deployed URL. 2. Review header grades, TLS/cert status, and DNS/email-auth results. 3. Act on failures — e.g., an expired cert rolls the release back.

Edge cases & gotchas

These are external checks on the live site, distinct from the pre-deploy code scan.
Dangling DNS records are flagged specifically because they enable subdomain takeover.

Runbooks

What it is. AI-generated operational runbooks for a project (/runbooks) — saved procedures for recurring tasks. Team+ tier.

Why it matters. Turns tribal ops knowledge into repeatable, shareable procedures.

Walkthrough

Open Runbooks → New Runbook. 2. Provide the project name and optional app URL. 3. ZipLoom generates the runbook; regenerate to refresh it. 4. Select a runbook from the list to read it.

Edge cases & gotchas

Team+ feature.
"No runbooks yet." / "Select a runbook to read it." are the empty/idle states.

Logs & Audit Events

What it is. The event/audit log (/logs) — actions in your workspace, filterable by actor and level (Info / Warn / Error). Guild tier.

Why it matters. Traceability — who did what, and what the platform did, across deploys and settings.

Walkthrough

Open Logs. 2. Filter by actor (or "All actors") and by level. 3. Review the event stream.

Edge cases & gotchas

Guild feature. (A separate, org-wide audit log of settings changes also appears under Settings.)

Costs & AI Spend

What it is. Cost visibility (/costs) across deploys and AI usage: Total This Period, Spend by Model, By Provider, Cache hit rate, BYOK Revenue, MRR Cost Ceiling, and a Budget Alert.

Why it matters. AI and infra spend can creep; this keeps it visible and bounded.

Walkthrough

Open Costs. 2. Review the period total, spend by model/provider, and recent events/requests. 3. Set a Budget Alert — "Notify when monthly spend exceeds a threshold." 4. Watch the MRR Cost Ceiling (Breached shows when exceeded).

Options & settings

Budget Alert threshold; monthly cost reset (llmCosts.resetMonthlyCosts).
BYOK (bring-your-own-key) revenue tracking.

Edge cases & gotchas

"No cost data yet" / "No AI calls this period" until usage accrues.

In-App Debug Copilot

What it is. A conversational debugging assistant built into the deployment view. Paste an error log or describe what went wrong, and it answers with your project's context already loaded — the build output, the detected stack, and the deployment history.

Why it matters. The usual loop is: copy the log, paste it into a separate chat, strip anything sensitive, re-explain your stack, repeat. The copilot starts from the deployment it's attached to, which removes the busywork and the risk of pasting a key into a tool that shouldn't see it.

Walkthrough

Open the failing deployment (Deployments → the run).
Scroll to the debug assistant. Paste the error log or describe the issue in the composer ("Paste error log or describe the issue…").
Read the diagnosis. It names the likely cause rather than restating the error.
Use Copy response to hand the fix to the AI tool that wrote the code.
Apply the change and redeploy. The next run's logs and findings are attached to the new deployment record.

Typical prompts it's built for: - "My deploy failed — here's the error log." - "My app builds locally but fails on the platform. Why?" - "How do I add environment variables to my deployment?" - "Why is my app returning 500 errors in production?"

Options & settings

Copy response — one-click copy, formatted to paste into a coding agent.
Context — scoped to the deployment you opened; open a different run to ask about that one.
Free-form input — a pasted log and a plain-language question both work.

Edge cases & gotchas

It explains and suggests; it does not change your code. Applying the fix stays your decision.
It answers from the context it has. A problem that lives outside the deployment — a third-party outage, a DNS change made elsewhere — may need information it can't see.
Don't paste anything into any assistant you wouldn't want stored. That applies here as much as anywhere else.
For a build that failed outright, the deployment record already carries the automatic failure diagnosis (see Deploying a Project); the copilot is for asking follow-up questions.

Self-Host Export (No Lock-In)

What it is. Download your Dockerfile, Terraform, and .env template at any time — "leaving takes an afternoon."

Why it matters. No lock-in. If you ever leave ZipLoom (including at acquisition/hand-off), you take a working, self-hostable stack with you.

Walkthrough

From a project, request the export. 2. ZipLoom generates the Dockerfile, Terraform (infrastructure), and a .env template. 3. Download and run it on your own infrastructure.

Edge cases & gotchas

Secrets are provided as a template, not populated — fill in your values from your Secrets Vault.

White-Label the Dashboard

What it is. Put your logo and brand colour on the workspace your clients see, and serve it on your own dashboard address (subdomain). Configured in Settings → Branding.

Why it matters. Agencies/consultants can present the platform as their own to clients.

Walkthrough

Settings → Branding: set Logo URL and Accent colour → Save branding.
Set your Dashboard address (subdomain) → Save address.
Clients see your brand, not ZipLoom's.

Options & settings

Logo URL, Accent colour, Dashboard address (subdomain).
Only owners and admins can change branding.

Edge cases & gotchas

White-label availability is plan-gated (see Billing — appears on higher tiers/Agency).

Governed Safety Rules

What it is. The rules that judge your code are versioned and change only through a reviewed pull request — the "Brain" behind the scanner.

Why it matters. You (and an acquirer) can see exactly what the platform enforces and how it changed over time — no silent rule changes.

Walkthrough

Security checks (Code/RLS/auth/secrets/deps/licenses) are driven by the governed rule set. 2. Any change to a rule goes through a PR review, so it's auditable. 3. The same rules drive both the in-app scan and the ziploom/scan-action in CI, keeping them consistent.

Edge cases & gotchas

This is what keeps pipeline and deploy scanning identical — one governed source of rules.

Settings & Workspace

What it is. Account and organization preferences (/settings): profile, branding, dashboard address, API keys, repository access, and the organization audit log.

Walkthrough

Profile — name/details; email is "managed by your sign-in provider."
Branding (owners/admins) — Logo URL, Accent colour → Save branding (see White-Label).
Dashboard address — your subdomain → Save address.
API keys — "Generate a key for the ZipLoom CLI" for CLI and programmatic access. ("No API keys yet" until created.)
Repository access — manage GitHub repo access for deployments.
Audit log — "Recent actions in this organization."
Account deletion — request deletion (requestDeletion).

Options & settings

Sub-pages: Team, Billing, Deploy Targets, AWS (BYOC), MCP Servers.

Edge cases & gotchas

Only owners/admins can change branding and org-level settings.

Team & Roles

What it is. Manage who has access to the organization (/settings/team) — invite members and assign roles.

Walkthrough

Open Settings → Team. 2. Invite by email ("teammate@company.com"). 3. Assign/adjust a role: Owner / Admin / Member (updateMemberRole). 4. Remove a member when needed.

Options & settings

Roles: Owner (full control), Admin (manage settings/branding), Member (use the workspace).

Edge cases & gotchas

"No members yet." until you invite someone. Some actions (branding, billing) are owner/admin-only.

Billing & Plans

What it is. Plan and billing management (/settings/billing): current plan, current usage, plan tiers, and the billing portal. Pricing is a flat subscription — no usage meters and no per-seat charges: Solo $20/mo, Guild $40/mo, Studio $70/mo, Business $299/mo, with a discount for annual billing (Solo $216/yr · Guild $432/yr · Studio $756/yr · Business $3,228/yr). Every feature is on every tier.

Walkthrough

Open Settings → Billing. 2. See Current Plan and Current Usage. 3. Checkout to change plans, or open the portal (Stripe) to manage payment, switch plans, apply promo codes, or cancel.

Options & settings

Tiers include Free Forever, a "Most Popular" tier, Agency Pro, and White-label. Higher tiers unlock features gated as Business+, Team+, Guild across the app.
Billing portal handles plan-switching, promo codes, and the cancellation survey.

Edge cases & gotchas

Feature gates map to tiers — e.g. Auto-Rollback/Change Impact/Synthetic Monitoring are Business+; Runbooks Team+; Logs Guild; White-label on Agency/higher.

AWS (BYOC — Bring Your Own Cloud)

What it is. Connect your own AWS account (/settings/aws) so deploys run in infrastructure you own. Business tier.

Walkthrough

Open Settings → AWS. 2. Enter your AWS Access Key ID and Secret Access Key → Connect. 3. Verify the connection. 4. Deploys can now target your AWS. Disconnect to stop.

Edge cases & gotchas

Business-tier feature.
Credentials are stored to run deploys in your account — the infrastructure and data stay yours.

MCP Servers

What it is. Register external MCP (Model Context Protocol) server connections for your organization (/settings/mcp-servers).

Walkthrough

Open Settings → MCP servers. 2. Add a server: Name (e.g. Notion), URL (https://mcp.example.com/mcp), optional Auth token (encrypted at rest), and description. 3. Test connection to confirm it authenticates. 4. Registered servers appear under Registered servers (Authenticated status).

Edge cases & gotchas

Auth tokens are encrypted at rest.
"No MCP servers registered yet." until you add one.

Founding Member Plans

What it is. Founding-member pricing and one-time offers (/founding).

Walkthrough

Open Founding. 2. Choose an option and go through founding checkout. Options include First Thread — Founding Solo, Founding Guild — 5 Seats, Thread Spool, and White-Glove Weave. 3. Review What is included before checkout.

Options & settings

Founding (subscription-style) and one-time checkouts (billing.foundingCheckout / oneTimeCheckout).

Edge cases & gotchas

Founding offers are limited-time/limited-seat by nature.

ZipLoom Documentation

Getting Started

Walkthrough

Options & settings

Edge cases & gotchas

Related

Projects

Walkthrough

Options & settings

Edge cases & gotchas

Related

Deploy Targets

Supported targets

Walkthrough

Options & settings

Edge cases & gotchas

Related

Deploying a Project

Walkthrough

Options & settings

Edge cases & gotchas

Related

AI Builder / AI Assistant

Walkthrough

Options & settings

Edge cases & gotchas

Related

Templates

Walkthrough

Options & settings

Edge cases & gotchas

Related

Discover

Walkthrough

Options & settings

Edge cases & gotchas

Related

Multi-Platform Deployment

Walkthrough

Options & settings

Edge cases & gotchas

Related

Security Scanning (Pre-Deploy)

The five checks (tabs)

Walkthrough

Options & settings

Edge cases & gotchas

Related

Findings & Finding Memory

Walkthrough

Options & settings

Edge cases & gotchas

Related

Secrets Vault (AES-256-GCM)

Walkthrough

Options & settings

Edge cases & gotchas

Related

Secrets Detection

Walkthrough

Edge cases & gotchas

Related

Vulnerable Dependency & License Audit

Walkthrough

Edge cases & gotchas

Related

Auth Audit & Lockdown (RLS) Check

Walkthrough

Edge cases & gotchas

Related

GitHub Actions Integration & Compliance Mapping

Walkthrough

Edge cases & gotchas

Related

Staged / Canary Rollout

Walkthrough

Options & settings

Edge cases & gotchas

Related

Auto-Rollback