Websites and backends

Your agent can publish websites and work with backends in the same workspace, paid from the same wallet. One static website per workspace is free; backends (PocketBase) are paid plans.

Static websites

Publish built HTML/CSS/JS, React/Vite applications and static framework exports on a kill.lat address. Sites start with a random subdomain; choose a custom label under Kilat address on either plan. Build locally, in CI or with your agent; Kilat hosts finished browser assets, not source builds.

Server-side rendering, API routes, serverless functions and arbitrary backend processes are not supported. Keep source code and dependency lockfiles in your own project backup.

Plans and limits

MiB means 1,048,576 bytes. Upload grants count toward the daily limit even if unused. Pending uploads are bounded; unused artifacts expire after one day. No bandwidth allowance is promised. Creation requires available host capacity and operator-configured DNS/runtime connectivity.

Create and publish

1. Open Websites → New static site. Confirm your email, complete the security challenge, choose a region and select Free or Paid. Paid creation debits your wallet for a 30-day term.
2. Optionally link a PocketBase service in your workspace. Linking exposes its public API URL and status, not admin credentials; it does not change collection rules or schema.
3. Build your frontend. Archive the contents of its output directory, not the directory itself:

npm ci
npm run build
tar --format=ustar -czf site.tar.gz -C dist .

The npm commands assume an existing project with a lockfile and build script. For Vite, build first and package only dist contents; never archive the project root or node_modules. Plain HTML sites only need the archive command, using their asset directory instead of dist. Include a nonempty index.html at the archive root. USTAR is recommended; bounded standard POSIX PAX metadata is also supported. GNU extensions, vendor-specific PAX attributes, symbolic links, hard links, traversal paths and special files are rejected. If your tar tool adds unsupported metadata, repack with the exact --format=ustar command above. Replace links in your build output with regular public files; do not package source or secrets.

4. Select the archive on your website page. Enable SPA navigation fallback for client-side routing, then select Upload build. A ready release is validated but not yet public.
5. Select Publish for the release. Runtime activation and public HTTPS receipt verification are separate steps; wait for the dashboard to record the active release before reporting success.
6. Open the site and check its content, navigation and assets. Use Rollback on a retained release to replace current content without changing the hostname.

Missing asset paths return 404. SPA paths containing a dot may also return 404 rather than index.html. Runtime activation failure restores previous content; failed public verification requests rollback. Candidate content can briefly be visible before external verification finishes. A running container alone does not prove working DNS, TLS or publication.

Upgrade, renewal and recovery

On an accessible free site, Pay & upgrade starts a paid 30-day term and preserves its hostname. Runtime limits are reconciled for an existing deployment. Paid pages expose auto-renewal controls and the custom-domain panel; DNS ownership verification is required. Free sites can rename their kill.lat subdomain; connecting your own domain requires Paid. Published-address changes retain the old route until cutover succeeds; unused sites rename immediately.

Free sites suspend after 90 days without publishing or owner sign-in, followed by seven-day recovery retention. Paid sites follow billing expiry and retention rules and never silently downgrade. Suspended sites require support recovery; an upgrade is rejected before charging and does not bypass suspension.

Public assets and PocketBase

Every browser asset is public, including build-time frontend environment values embedded in JavaScript. Never upload provider keys, MCP/upload tokens, .env files, private keys or PocketBase superuser credentials. Automated file rejection cannot prove an artifact free of secrets.

Browser clients use PocketBase end-user authentication and collection rules. CORS is not authorization. If the linked backend is suspended or deleted, the frontend can keep serving but may no longer load application data; linking does not guarantee backend availability.

Publish with your agent and MCP

The updated agent image includes the kilat-create-website skill and auto-connects newly created agents with dedicated publishing credentials. Such agents can create the workspace's available free site after email verification without a separate manual MCP approval. They cannot purchase or upgrade: paid tiers require the owner's dashboard action. Existing agents/manual tokens keep the explicit approval flow below. Wrapper image rollout is required.

For manual connections, create the site in Websites first, or select Approve free creation through MCP instead. Under Account → MCP, enable Site publish on a trusted token. Existing read/manage scopes do not grant publication. A site-bound token sees only its selected site and cannot create another; paid purchases remain dashboard-approved.

Keep MCP credentials in the agent's private environment, never in frontend assets. Upload grants are single-release, short-lived and single-use; keep them out of URLs and logs. Publishing and rollback replace public content and require client approval. Follow the Kilat Agent publishing walkthrough and MCP tool reference for arguments, expected-release checks and retries.

Backends (PocketBase)

PocketBase is an open-source backend in one app: a SQLite database, user authentication, file storage, realtime APIs, and an admin dashboard. It is part of Kilat's launch catalog.

Plans

PocketBase does not need an AI model key.

Pro allocates 1 GB RAM and 1 vCPU for Rp25,000 per 30 days (Rp50,000 list, current 50% discount). More resources provide headroom, not a workload guarantee; deployment depends on host capacity.

First login

1. Deploy PocketBase from the catalog.
2. Kilat creates a superuser with your account email and a random password before the app goes public.
3. Reveal the initial credentials on the service page, sign in to the PocketBase dashboard at /_/ on your service address, and change the password.

Your new password is kept across restarts and recreation; Kilat does not reset it.

Securing your data

• Set API rules on every collection before you point a website or app at it. Collections with open rules are public.
• Keep superuser credentials private and never send them by email, including to support.

Backups

All data lives in PocketBase's pb_data storage, which survives restarts and recreation. That is not a backup: use PocketBase's built-in backups or export your data regularly.