# Sites

Every organization can publish one static website, served from a repo's `main` branch at:

```text
https://<organization>.oak.space/
```

Your personal organization's site is `https://<username>.oak.space/`. Merge to `main` and the site updates — there's no build or deploy step.

## Turn it on

From inside a checkout of the repo you want to publish:

```bash
oak site enable                          # serve this repo's main branch from the root
oak site enable --source public          # …or from a subdirectory
oak site enable --repo acme/website      # …or name the repo explicitly
```

Then check it:

```bash
oak site show
oak site list         # every site you can see
oak site disable      # take it down
```

Over the API: `PUT /api/orgs/{slug}/site` with `{"repo": "website", "source_dir": "public"}`, `GET` to read it, `DELETE` to disable. Managing a site needs admin rights on the organization.

## How files are served

- The URL path maps onto files under the source directory at the tip of `main`.
- `/` serves `index.html`. A path like `/blog/` serves `blog/index.html`, and `/about` tries `about` and then `about/index.html`.
- If nothing matches, a `404.html` at the root of the source directory is served (with status 404), if there is one.
- Content types come from file extensions.

It's purely static: no server-side code, redirects file, or build step. Build your site in CI or locally and commit the output, or commit a site that needs no build.

## Visibility

**A site is public**, even when its repo is private — enabling it is the decision to publish. [Path permissions](/docs/path-permissions) still apply: files restricted in the repo are never served.

## Custom domains

There's no built-in custom-domain support yet. To serve a site at your own domain, put a reverse proxy or CDN in front of `<organization>.oak.space`.