Frontend workers

Frontend workers serve a static site or SPA from a zip you upload. Zip the output folder that has index.html at the top — a React or Vue npm run build, a Next.js static export, or plain HTML. TaruviBase serves the version you mark as active.

How it fits together

Each worker has a name and a sub-domain. You can optionally link a worker to an app for organization.

What you can do

Goal	Where to start
First deploy	Get started
Create, manage workers, upload builds	Get started
REST API, archive rules, access	API and archive reference
Something failed	Troubleshooting

Important details

• API lives under /api/cloud/frontend_workers/ (cloud scope—not nested under a single app path).
• Each archive is limited to 10 MiB and must include index.html at the root of what you deploy.
• Do not put .env files in the root of the zip—uploads are rejected.
• Each worker gets its own web address, made from its subdomain. On development and staging sites the subdomain gets an environment prefix, such as dev-. The Console shows the address on the worker's page.

How to integrate

In TaruviBase Console, open your site's Frontend tab and select Deploy Frontend Worker. The form collects the worker name, optional custom subdomain, optional associated app, and a zip of your build—then creates the worker and uploads the archive in one action.

For CI/CD, mirror that flow:

1. Build your site (for example npm run build).
2. Zip the output so index.html is at the archive root and the file stays under the 10 MiB limit.
3. Deploy with a multipart POST /api/cloud/frontend_workers/ (name, optional subdomain_input and app, and [email protected]). Upload later versions with a multipart PATCH to the worker.
4. Go live with set_active=true on the upload, or choose any finished build with PATCH …/set-active-build/.

Step-by-step Console and curl examples are in Get started.

Before you rely on deploy automation in production, test access with an allowed and a denied account; see Security and access.