# W7S Documentation

> W7S documentation explains how to deploy static frontends, JavaScript/TypeScript native backends, fullstack apps, storage bindings, queues, workflows, custom domains, observability, usage accounting, and self-hosted W7S clouds.

Use this file as the compact docs map. Use the full docs context when an agent needs detailed configuration examples or API shapes.

Important notes:
- W7S deployments are usually started from GitHub Actions.
- Static frontend outputs are discovered from common build directories such as `dist/`, `build/`, `out/`, `dist/client/`, and `frontend/dist/`.
- Native backends are JavaScript or TypeScript Worker modules from `backend/` or `worker/`.
- Self-hosting uses the same open source core behind W7S Cloud.

## Docs

- [W7S](https://w7s.io/docs/): W7S is an open source deployment platform managed directly from GitHub Actions workflows. The same W7S core can power other deployment clouds.
- [Deploy From GitHub](https://w7s.io/docs/deploy-from-github/): W7S deploys are authorized with the repository's GitHub token. If the workflow token can read the repository, it can deploy that repository to W7S.
- [Self Host W7S](https://w7s.io/docs/self-host/): W7S is open source. The hosted `w7s.cloud` service is one deployment of the W7S core Worker, and you can run the same core on your own Cloudflare account and domain.
- [Recommendations](https://w7s.io/docs/recommendations/): Add a separate GitHub Actions workflow that runs once per day to check W7S usage limits without deploying the app.
- [Security](https://w7s.io/docs/security/): This page is for developers deploying frontend and backend applications on W7S.
- [Pricing](https://w7s.io/docs/pricing/): w7s.cloud is free to start. You do not need a W7S account, a credit card, or a separate cloud setup to deploy through the hosted service.
- [Project Layouts](https://w7s.io/docs/project-layouts/): W7S detects deploy targets from the archive uploaded by GitHub Actions.
- [Local Development](https://w7s.io/docs/local-development/): `w7s-local` runs a local `workerd` router that mirrors the W7S URL shape. Use it when you want to test a frontend, backend dev server, or fullstack app with the same owner, repo, branch, and path routing model that W7S uses after deploy.
- [Storage Bindings](https://w7s.io/docs/storage-bindings/): JavaScript/TypeScript native W7S backends can declare durable resources in `w7s.json`. W7S creates one set of resources per repository and environment, then reuses them on later deploys.
- [Serverless Database](https://w7s.io/docs/serverless-database/): W7S can provision a serverless DB for a JavaScript/TypeScript native backend. Declare the database in `w7s.json`, keep SQL migrations in the repo, and read the binding from `env.DB` inside the backend worker.
- [Stateful Objects](https://w7s.io/docs/backend-durable-objects/): JavaScript/TypeScript native W7S backends can declare stateful object classes in `w7s.json`. W7S creates persistent classes the first time it sees them and binds each class to the backend by name.
- [Postgres Bindings](https://w7s.io/docs/backend-hyperdrive/): JavaScript/TypeScript native W7S backends can declare managed Postgres bindings in `w7s.json`. These bindings let backend modules connect to external Postgres databases through the W7S-managed connection layer.
- [Backend AI](https://w7s.io/docs/backend-ai/): JavaScript/TypeScript native W7S backends can use W7S AI without adding provider credentials to the repo. W7S injects these bindings during deploy:
- [Backend RPC](https://w7s.io/docs/backend-rpc/): JavaScript/TypeScript native W7S backends can call other W7S backends without going through public DNS. W7S injects an internal service binding and a per-deployment token into every JavaScript/TypeScript native backend.
- [Backend Queues](https://w7s.io/docs/backend-queues/): JavaScript/TypeScript native W7S backends can declare queues in `w7s.json`. W7S creates the managed queue, connects it to the W7S control plane, and delivers batches to the declaring backend.
- [Backend Workflows](https://w7s.io/docs/backend-workflows/): JavaScript/TypeScript native W7S backends can declare workflow consumers in `w7s.json`. W7S owns the workflow runner, creates instances for app requests, and dispatches each instance to the declaring backend through a durable step with retries.
- [Backend Schedules](https://w7s.io/docs/backend-schedules/): JavaScript/TypeScript native W7S backends can declare cron schedules in `w7s.json`. W7S runs one managed scheduler every minute, checks deployed app schedules, and dispatches due jobs to the declaring backend.
- [Usage Accounting](https://w7s.io/docs/usage-accounting/): W7S records daily usage rollups for each deployed repository and environment. W7S-managed paths update counters directly, and direct runtime and storage usage is synced hourly from platform telemetry into the same rollup.
- [Observability](https://w7s.io/docs/observability/): W7S exposes two observability streams:
- [URLs And Routing](https://w7s.io/docs/urls-and-routing/): W7S maps GitHub repositories to public URLs on `w7s.cloud`.
- [Custom Domains](https://w7s.io/docs/custom-domains/): Add a `CNAME` file to claim one or more custom hostnames for a deployment.
- [Deploy API](https://w7s.io/docs/deploy-api/): Most users should deploy with `w7s-io/w7s-cloud@v1`. The deploy action calls the W7S deploy API.
- [Examples](https://w7s.io/docs/examples/): Use these repositories as starting points.

## Optional

- [Full W7S docs context](https://w7s.io/docs/llms-full.txt): Complete generated Markdown context for all docs pages in sidebar order.
- [W7S landing page](https://w7s.io/llms.txt): Agent-friendly overview of the main W7S website.