From files to a website
you can share.
This guide describes the running beta. It makes a clear distinction between the publishing path you can use today and the services still being built.
Find your next step
1. Prepare your files
For a simple HTML website, put index.html and its assets in a ZIP. For Vite, React or another frontend project, run the project's production build and ZIP its output directory. Do not include node_modules, .git, .env files or private keys.
Static means there is no server process in this release. A Node API, Python app or Next.js server-rendered app needs the later isolated runtime service. Static exports can be uploaded now.
2. Inspect before publishing
Create a project, select your ZIP and choose Inspect files. DeployBeacon checks filenames, archive sizes, symlinks, duplicate entries, sensitive file names, recognizable embedded credentials and the HTML entry point. Review the selected document root and findings. Credential checks run locally and show no secret values. If a key is found, remove it, rotate any exposed credential and rebuild. Public Stripe and Supabase keys are allowed, but their server-secret counterparts are not. Obfuscated, encoded or unknown secrets can still be missed; these checks are not a complete malware or application-security audit. Publishing and preview promotion repeat the checks.
Import a public GitHub repository
In your project, open Import from public GitHub. Enter its repository URL and optionally a branch, tag or commit. Import & inspect resolves a fixed commit, downloads a bounded archive and runs the same safety checks as a ZIP upload. It does not change your live site. Re-import when you want a newer revision; automatic push deploys and private GitHub connections are not available yet.
The repository must contain built HTML, CSS and JavaScript. We do not run its build commands or fetch submodules/Git LFS. If source files need compilation, build locally and upload the output ZIP. Public GitHub rate limits may require waiting before retrying.
Send a small website directly from your assistant
A compatible MCP assistant can call files_inspect with an existing project ID, confirm: true and a files array. Each file has a plain relative path, content and optional encoding: utf8 for text or base64 for binary. Up to 50 files and 512 KiB of decoded content fit in one submission (1 MiB request limit). Larger websites still use ZIP upload. Send built files, never credentials or server source.
The same safety and storage checks apply. This creates a private inspection, not a live deployment. Read its findings, then ask the assistant to propose publication. Review the exact project and files in Agent approvals before approving. The assistant cannot approve its own proposal. Direct API and CLI tokens can publish with explicit confirmation, so only give deployment-write permissions to tools you trust.
For scripts, use POST /api/v1/projects/PROJECT_ID/file-imports or save a JSON object containing the files array and run:
node deploybeacon.mjs inspect-files PROJECT_ID manifest.json --confirm
3. Publish and verify
Choose Confirm & publish. The service prepares a new release and makes an HTTP request to its candidate page. It selects the release only after that check passes. Open View website and exercise your own links and interactions. An HTTP check does not prove every application feature works.
Preview URLs use a separate sandboxed origin and a path prefix. Simple HTML asset URLs are adjusted for the prefix. Custom domains support root-relative asset paths. Shared platform and preview addresses remain sandboxed in this beta: cookies, local storage and browser features requiring a normal same-origin context are unavailable there. Verified customer-owned custom domains use their own browser origin with normal storage support.
Static redirects and response headers
Your built website can include optional _redirects and _headers files in its selected document root. Inspection validates supported paths, statuses and response fields. Rules can redirect pages or rewrite to a local static file; they cannot run a backend or override platform security and private-preview protections. See the supported format, examples and limits.
Preview without changing your live site
After inspection, choose Prepare private preview instead of Confirm & publish. Open the release and create a link lasting one hour, one day or seven days. Anyone with this bearer link can view the release; it is not an account-protected login. Links are shown once, can be revoked, and do not grant dashboard access. When satisfied, choose Publish preview and confirm to replace the live website.
Unused releases can be retired by an owner or admin. Retirement revokes preview links immediately and frees a release slot. Files stay recoverable for seven days and still count toward storage during that time. Daily cleanup then removes only their extracted files. The original ZIP and audit history remain, and you can export the original ZIP from release details. Your selected live release cannot be retired.
To remove an original ZIP separately, open Usage & plans → Stored uploads. Only an owner or admin can schedule removal, and only after no live, in-progress or retained release needs it. Download a copy, type its filename and confirm your password (plus a fresh authenticator code if enabled). Cancel removal within seven days. Storage is freed when daily cleanup removes the file; record history and copies inside prior encrypted backups remain. Uploading the identical original again restores it. This is not account-data erasure.
4. Roll back
Open a previous successful release and choose Restore release, then confirm. Its retained files become the selected website. Failed releases cannot be restored. Publishing and restoring are both recorded in Activity log.
5. Connect a domain
Add a domain you own and select a published project. Copy both the A and ownership TXT records into your DNS provider, use DNS-only mode, then choose Check DNS. Free includes one custom domain. After ownership and routing checks pass, DeployBeacon automatically requests an HTTPS certificate and connects the project. Wait for Connected · HTTPS before sharing the address. Keep the TXT record in place. IPv6, wildcard domains and proxied DNS are not supported in this beta. Disconnect stops serving the project; remove its DNS records separately at your provider.
6. Use the CLI or API
Create a token in Access & security. Choose only the scopes your tool needs. Download the CLI from Integrations and use Node.js 22 or later. Keep the token in an environment variable, never in source control.
# Set these privately in your terminal DEPLOYBEACON_URL=https://deploybeacon.ai DEPLOYBEACON_TOKEN=<your-scoped-token> node deploybeacon.mjs projects node deploybeacon.mjs create "My website" node deploybeacon.mjs inspect PROJECT_ID built-site.zip node deploybeacon.mjs deploy INSPECTION_ID --confirm node deploybeacon.mjs release RELEASE_ID node deploybeacon.mjs rollback RELEASE_ID --confirm
REST writes use a bearer token. Publishing also requires an Idempotency-Key header and a confirm flag. The API reference describes the implemented routes.
7. Connect a compatible MCP client
Use the /mcp endpoint with Streamable HTTP and Authorization: Bearer followed by your token. Current tools list projects, submit and inspect small built websites, read release evidence, propose publishing/rollback and execute an approved proposal. OAuth clients can discover permissions at this endpoint, register a public client using PKCE S256, and send the MCP endpoint as the resource during sign-in and token exchange. Choose the workspace and permissions on the consent screen. Revoke connections in Access & security. Individual clients, including ChatGPT, are not claimed as certified or tested until their own connection journey is completed.
The assistant's proposal appears in Agent approvals. Check its exact target before approving. The assistant then executes it and receives the recorded outcome.
What is still being built?
Dynamic app workers, automatic Git push deployment/private Git-provider connections, managed customer databases, object storage, customer outgoing email delivery, payment subscriptions and a production abuse-response operation. Plan prices are indicative and no charges are collected. The control plane has its own PostgreSQL database, but that is not a customer database-hosting feature.
Access and support
This deployment is an operator-controlled private beta. Registration is closed. Sign in with your own invited account. Keep tokens private and retain the error code and reference ID if a request fails.