> For the complete documentation index, see [llms.txt](https://docs.layeronecloud.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.layeronecloud.com/platform/overview.md).

# Platform at a glance

LayerOne Operations is the production platform for LayerOne LLC's hosting business.

## 0.1 Three audiences, one codebase <a href="#id-01-three-audiences-one-codebase" id="id-01-three-audiences-one-codebase"></a>

LayerOne Operations is the production platform for LayerOne LLC's hosting business. One Django project serves:

1. **Public marketing site** — homepage, pricing, features, blog, contact, looking glass, public status, help center, and CMS-managed pages. Served at the site root (`apps/marketing`, `apps/core`).
2. **Client portal** (`/client/...`) — order VPS and shared hosting, pay, manage services, credit, payment methods, networking, referrals, API keys, browser VNC console (`apps/billing` public views, `apps/webhosting`, `apps/api`).
3. **Operations console** (`/console/...`) — tickets, incidents, monitoring, inventory, audit, billing administration, CMS, email campaigns. Client ticketing deliberately lives at `/console/tickets/`, not under `/client/`.

## 0.2 Runtime and deployment <a href="#id-02-runtime-and-deployment" id="id-02-runtime-and-deployment"></a>

Deployed on **Railway** from the repository `Dockerfile`. Production is Django/ASGI (uvicorn) + PostgreSQL + Redis + Celery worker + Celery Beat.

`LAYERONE_PROCESS_TYPE=all` (the Docker default) starts web, worker and Beat in every replica; a PostgreSQL advisory lock elects exactly one active Beat and the rest stand by. Splitting into `web` / `worker` / `beat` services is optional and only for independent scaling. In split mode apply the `/health/live/` HTTP healthcheck to `web` only — Celery binds no port.

Local development needs no PostgreSQL, Redis, Stripe or Proxmox: SQLite, LocMem cache, eager Celery, console email, and **dry-run provisioning** (`BILLING_PROVISIONING_LIVE=False`). The money side is fully live locally; the hypervisor side is a stub.

## 0.3 App map <a href="#id-03-app-map" id="id-03-app-map"></a>

```
apps/
  accounts/        Identity, sign-in, access modes, staff roles, MFA, passkeys, activity
  api/             Client API, API keys, Organization settings → API, request metering
  billing/         Catalog, wallet, orders, Stripe/PayPal, provisioning, Proxmox, IPAM,
                   VMs, organizations and tenants, statements, insights, rewards
  webhosting/      Shared-hosting catalog, CloudLinux nodes, management jobs, DNS, mail
  paas/            Application platform: apps, builds, releases, microvm placement,
                   private projects, router config, GitHub deploys
  core/            Dashboards, public status, health, email transport, agent API, deploy_release
  marketing/       Public site, CMS pages, blog, looking glass, promo landing pages
  sites/           Multi-site configuration and template context
  status_pages/    Public status-page data model
  tickets/         Client and operations ticketing
  incidents/       Incident lifecycle and public publication
  infrastructure/  Device inventory and topology
  monitoring/      Checks, outages, uptime, remote agents
  audit/           Append-only operations audit trail
  campaigns/       Lifecycle and marketing email
  referrals/       Refer-a-friend and affiliate programs
  recordings/      First-party session replay of public site and /client/
  network_alerts/  LayerOne Aegis: DDoS incidents, telemetry, port scans
  assistant/       Chat dock, live handoff, help-center knowledge index
config/settings/   base.py (shared), local.py (dev default), production.py (Railway)
```

`config/urls.py` composes the routes. Django admin is mounted at `/console/django-admin/`. `/r/`, `/email/`, `/api/`, `/docs/` and `/downloads/` are mounted **ahead of the marketing CMS catch-all**, or a CMS page created at one of those paths would swallow the feature.

## 0.4 Settings and environment <a href="#id-04-settings-and-environment" id="id-04-settings-and-environment"></a>

`config/settings/base.py` holds shared defaults; `local.py` is the `manage.py` default; `production.py` requires `DATABASE_URL`, `ALLOWED_HOSTS` and friends and fails fast when a production service is unconfigured. See [Appendix A](/platform/reference/environment-variables.md) for the variable reference and `README.md` for deployment order.

## 0.5 Local development accounts <a href="#id-05-local-development-accounts" id="id-05-local-development-accounts"></a>

`manage.py create_debug_accounts` creates four development-only logins and fills the three client ones with sample data through the **real services**, so the seeded accounts are a shape the application can actually produce (`apps/accounts/debug_seed.py`):

| Login          | Password       | What it is                                         |
| -------------- | -------------- | -------------------------------------------------- |
| `admin`        | `admin`        | Super admin staff; lands on the operations console |
| `user`         | `user`         | Client with two servers                            |
| `organization` | `organization` | Client owning an organization with two tenants     |
| `orguser`      | `orguser`      | **Member** of that organization; no billing access |

The names live in `DEBUG_ONLY_ACCOUNT_EMAILS` (`apps/accounts/utils.py`) because that set is the security boundary: the commands refuse to run unless `DEBUG=True`, and `DebugOnlyAdminAwareModelBackend` refuses **every name in the set** whenever `DEBUG` is False — which covers the sign-in view, Django admin's login form and `get_user()` at once. A guard written per-account is how the second one ships live. The sign-in page lists only the logins that actually exist, because advertising an unseeded one offers nothing but the deliberately generic failure message.

***


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.layeronecloud.com/platform/overview.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.