From draft to public website
Viking gives your team a private place to create a website and a separate public site for visitors. Site owners work in a browser; administrators provide the Kubernetes installation, storage, hostnames and sign-in service.
Two addresses, two purposes
| Address | Who uses it | What happens there |
|---|---|---|
CMS address, such as https://cms.example.net |
Authors and publishers who sign in | Edit pages, manage media and themes, preview, publish and roll back. |
Public address, such as https://example.com |
Website visitors | Read the active published website and download its public files. |
The public site serves generated static files. Visitor requests run independently of the editing application and sign-in service. Your team can edit drafts while visitors continue reading the last published version.
The publishing workflow
flowchart LR
E[Edit pages and design] --> S[Save drafts]
S --> P[Preview and review]
P --> B[Publish saved site]
B --> R[Complete public release]
R --> V[Visitors browse the site]
- Create: write in visual Markdown or Source mode, build visual pages from blocks, add downloadable files, or import WordPress content as drafts.
- Organise: choose page URLs, menu positions and parents. Add indexes or repeated cards to help visitors discover related content.
- Design: select a theme, customise a copy, and reuse shared headers, footers and layouts across the site.
- Save and preview: save drafts and settings, then review content at desktop, tablet and mobile widths. Preview stays private.
- Publish: Viking builds a complete release from saved pages, settings, the selected theme and uploaded assets, then switches the public site to it. The Publish site action saves the currently open page first; save work in other tabs and theme/settings workspaces separately.
- Verify: open the public site, follow links and check images and downloads. The default frontend refresh interval is about one second; external caching can add delay.
Every saved page and uploaded asset joins publication. Menu visibility controls navigation, so review menu-hidden pages and unused uploads too. Importing private WordPress posts as drafts makes them part of the next publication.
Releases and recovery
A release is a complete generated copy of your website with a number such as
000001. Administrators choose how many historical releases to retain. With
retained releases, a publisher can roll back public output without rebuilding it.
Saved drafts stay as they are; edit and republish to change them, or restore a
storage backup to recover lost source.
Read publishing and rollback before your first release, and arrange backups for editable recovery.
What administrators manage
Administrators declare each site with a Kubernetes Website resource. Viking's operator creates and maintains site workloads, storage claims and routing from those settings. The CMS uses private storage for editable content and writes generated releases to published storage. Public frontend replicas read only published files.
Plan DNS, ingress, TLS certificates, RWX storage and an OAuth2/OIDC sign-in provider before installation. Optional Ipseity integration provisions sign-in configuration and initial access. An explicit authentication Secret can connect another provider.
Keep the CMS at one replica with Recreate upgrades, and scale public frontend replicas independently. Keep health and metrics listeners inside the trusted network. Configure monitoring and storage backups through your platform, and use Website settings to manage the deployment.
Continue with getting started as a site owner or the operations guides as an administrator.