Create a CMS
Your operator must approve the CMS template, database plan and storage allocation for your project first. Installing the plugin does not allocate a CMS automatically for every project.1
Open the project plugin
Open CMS from your project’s installed plugins.
2
Create the instance
Enter a website name and select Create CMS. Webdock uses the operator-approved resources and image.
3
Follow setup progress
Webdock provisions the database and media volume, initializes the schema with separate migration credentials, starts the application and verifies its HTTPS address. You can leave the page and return later.
4
Open the editor
The native editor appears when the instance is ready. A repeated request reconnects to the same project instance; it does not create a second database.
Edit and publish
The initial template includes pages, text and image sections, SEO fields, media and site settings in English and German. Content language is selected separately from the interface language. Save a draft before publishing. Publication changes the public version; an unpublished edit remains private to authorized editors. Use Unpublish to take the selected language offline while keeping its content and history. If someone else saved a newer version, reload and reconcile your changes instead of overwriting theirs. Administrators can review and restore earlier versions. Media accepts single-frame PNG, JPEG, WebP and AVIF images up to 10 MiB and 40 megapixels. Add useful alternative text. SVG, HTML and animated uploads are rejected. Uploaded files are immutable in managed instances. To replace an image, upload a new media item and select it in the page; alternative text remains editable. This prevents a failed update from deleting a file still referenced by saved content. Administrators can remove managed media to trash. This hides it from normal editor lists and fresh public media requests while retaining its bytes. Trashed files still count toward storage and backups until a separate explicit operator purge; removal does not reclaim quota. A failed or conflicting removal keeps both the metadata and file. If a save has an uncertain outcome, check the content list before retrying. The editor blocks further mutations until you reconcile the saved state; it does not automatically repeat the write.
Your current website grants are checked on every request. A locally disabled account or a lower local role also restricts access. Plugin access does not grant arbitrary access to another project’s website.
Existing websites
An existing independent website can opt into the bridge while keeping its schema and content. The editor exposes only the collections and globals that website explicitly allows. Connecting it does not add the new-instance template or provide a general schema designer. The included existing-website integration uses PostgreSQL for its shared transfer journal, so uploads and mutation receipts survive separate serverless function instances. Run that website’scms:migrate with migration credentials before enabling its bridge, and grant the runtime access to the transfer tables. It does not use a local filesystem journal. See website integration.
Stop, disable and retain
Disabling the plugin revokes editing and further provisioning. Already published content continues serving, including certificate renewal. Suspend the application in Hosting to take the website offline. Both operations retain the database and media; permanent purge is separate. Keep matched database and media backups on a separately hosted destination. A retained disk or remount after reboot is not a backup. Restore into isolated resources and verify content and file hashes before making a restored instance public.Self-hosting requirements
Automatic provisioning requires the Full distribution with Hosting and Databases, migration 0048 or later, the updated managed agent, an approved immutable CMS image, a same-cluster managed PostgreSQL plan, persistent volume capacity and HTTPS publication. Core-only installations do not contain these product adapters. SetWEBDOCK_APPROVED_CMS_TEMPLATE on both the API and setup worker, and install the matching root-owned agent approval. The configuration pins the image, domain, ingress addresses, cert-manager ClusterIssuer, database plan and authentication issuer. Each instance has an exact-hostname Certificate, Ingress and TLS Secret issued and renewed by cert-manager. The agent does not copy a wildcard certificate or handle its private key; wildcard DNS still routes instance hostnames to the approved ingress addresses. Keep credentials out of plugin JSON configuration and source archives.
Before starting an updated CMS image, run its bounded migration job, including additive migration 20261018_201453_managed_media_trash. It adds media and version trash timestamps and indexes while retaining existing tables and files.
Use the operator runbook for exact configuration, migration recovery, certificate renewal and backup/restore commands. General deployment and licensing are covered in self-hosting Webdock.