Ghost

Overview

Ghost is the open-source publishing platform for professional blogs, newsletters, and paid memberships, with a first-class editor and REST Content/Admin APIs. This template deploys a single stateful Ghost workload backed by a bundled MySQL 8 database, with a durable content volume, an HTTPS public site on the auto-assigned canonical endpoint, optional SMTP email, and optional scheduled database backups to object storage.

This template deploys into an existing GVC that you already have — it does not create one.

What Gets Created

Resource	Name	Purpose	Optional
Workload	`RELEASE_NAME-ghost`	Ghost server — site, editor and Content/Admin APIs on port `2368` (stateful, 1 replica, container `ghost`)	—
Volume Set	`RELEASE_NAME-ghost-vs`	Content directory at `/var/lib/ghost/content`: uploaded images, themes, logs, adapters	—
Secret	`RELEASE_NAME-ghost-start`	Startup script that sets Ghost’s `url` and hands off to the image entrypoint	—
Identity & Policy	`RELEASE_NAME-ghost-identity`, `RELEASE_NAME-ghost-policy`	`reveal` on exactly the startup script, your database credentials secret, and your SMTP secret when `mail.secretName` is set	—
Workload	`RELEASE_NAME-mysql`	MySQL 8 database (stateful, 1 replica, container `mysql`, port `3306`) from the bundled mysql subchart	—
Volume Set	`RELEASE_NAME-mysql-vs`	MySQL data directory at `/var/lib/mysql`	—
Identity & Policy	`RELEASE_NAME-mysql-identity`, `RELEASE_NAME-mysql-policy`	`reveal` on your two database secrets; carries the cloud-account binding when backups are on	—
Workload	`RELEASE_NAME-mysql-backup`	Cron job running a scheduled `mysqldump` to S3 or GCS	`mysql.backup.enabled: true`

Prerequisites

Two database secrets must exist before you install; the chart never creates them. They hold credentials, so they are prerequisite secrets rather than values — a value would sit in plaintext in the Helm release for the life of the install. Secrets are org-level, so no GVC flag is involved.

Database credentials

A dictionary secret with keys username, password and database. MySQL is initialized with it on first boot, and Ghost connects with the same keys:

cpln secret create-dictionary --name my-ghost-db-credentials \
  --entry username=ghost --entry password='YOUR-STRONG-PASSWORD' --entry database=ghost

Set mysql.credentialsSecretName to this name.

MySQL root password

An opaque secret holding the MySQL root password, kept separate so Ghost never reads it:

printf '%s' 'YOUR-STRONG-ROOT-PASSWORD' | cpln secret create-opaque --name my-ghost-mysql-root-password --encoding plain -f -

Set mysql.rootPasswordSecretName to this name. The two names must differ.

If either database secret is missing, the install reports success and then waits silently: cpln logs shows nothing, and the missing secret is named only in status.versions[].message of cpln workload get-deployments RELEASE_NAME-mysql --gvc GVC_NAME -o yaml. The workload recovers on its own once the secret exists, or immediately after cpln workload force-redeployment RELEASE_NAME-mysql --gvc GVC_NAME.

Two optional features need setup before you install:

SMTP credentials (optional)

Member sign-in links, staff invitations and newsletters are sent over SMTP, and SMTP is off until mail.secretName names a dictionary secret holding exactly the keys user and password. Secrets are org-level, so no GVC flag is involved:

cpln secret create-dictionary --name SECRET_NAME \
  --entry user=smtp-username \
  --entry password='YOUR-SMTP-PASSWORD'

Set mail.secretName to this name, together with mail.host and mail.from — see Mail (SMTP).

Backup bucket and Cloud Account (optional)

Scheduled database dumps need an S3 or GCS bucket plus a Control Plane Cloud Account. See Backing Up.

Create the SMTP secret before installing with mail.secretName set. A name that points at a secret which does not exist installs “successfully” and then wedges silently: cpln logs shows nothing, and the only place the missing secret is named is status.versions[].message in cpln workload get-deployments RELEASE_NAME-ghost --gvc GVC_NAME -o yaml. The workload recovers on its own once the secret exists, or immediately after cpln workload force-redeployment RELEASE_NAME-ghost --gvc GVC_NAME.

Installation

A default install needs only the names of the two database secrets:

cpln helm install RELEASE_NAME oci://ghcr.io/controlplane-com/templates/ghost \
  --version 1.3.0 --gvc GVC_NAME \
  --set mysql.credentialsSecretName=my-ghost-db-credentials \
  --set mysql.rootPasswordSecretName=my-ghost-mysql-root-password

Or install using your preferred method:

UI

Browse, install, and manage templates visually

CLI

Manage templates from your terminal

Terraform

Declare templates in your Terraform configurations

Pulumi

Declare templates in your Pulumi programs

Configuration

Ghost Application

image: ghost:6.54.1-alpine # official Docker Hub image (library/ghost)

resources: # Ghost (Node) app — single instance
  maxCpu: 500m
  maxMemory: 1024Mi
  minCpu: 250m
  minMemory: 512Mi

# Persistent content: uploaded images, themes, logs, adapters (mounted at /var/lib/ghost/content)
volumeset:
  capacity: 10 # initial capacity in GiB (minimum is 10)

The resource block exposes both a floor and a ceiling, so the ceiling is named maxCpu / maxMemory — the bare cpu / memory names from template version 1.0.0 are refused at render (see Upgrading from 1.0.0). Media, themes and logs live on the content volume set; posts, members and settings live in MySQL.

Site URL

# Public URL Ghost uses to build links and emails. Leave empty to auto-derive the
# canonical *.cpln.app endpoint. Set to your custom domain once attached.
publicUrl: "" # e.g. https://blog.example.com

Ghost bakes its url into every page link, feed and email, and rejects admin requests whose origin does not match it, so it must be the address visitors actually use. The template sets it at container start through the RELEASE_NAME-ghost-start script, in this order:

Condition	`url` Ghost runs with
`publicUrl` is set	Exactly that value, including the `https://` scheme
`publicUrl` empty, `publicAccess.enabled: true` (default)	The workload’s canonical `*.cpln.app` endpoint, read at runtime
`publicUrl` empty, `publicAccess.enabled: false`	`http://RELEASE_NAME-ghost.GVC_NAME.cpln.local:2368`

Once you attach a custom domain to the RELEASE_NAME-ghost workload, set publicUrl to it (for example https://blog.example.com) and upgrade the release. The new value lands in the startup-script secret, not in the workload spec, so the running container keeps the old URL until it restarts — force a redeployment after the upgrade:

cpln workload force-redeployment RELEASE_NAME-ghost --gvc GVC_NAME

Mail (SMTP)

# Member sign-in links & newsletters. DISABLED while secretName is empty (email off).
# Prerequisite: create a dictionary secret with keys `user` and `password` BEFORE install.
mail:
  secretName: "" # e.g. my-ghost-smtp (dictionary secret with keys: user, password)
  host: ""       # e.g. smtp.mailgun.org
  port: 587      # 465 = SSL, 587 = STARTTLS
  secure: false  # true for port 465
  from: ""       # e.g. "Ghost <noreply@example.com>"

# Ghost 6 emails a 2FA code to staff on every new-device admin login, which needs
# SMTP. Default off so /ghost admin is reachable without mail; set true only after
# configuring mail above (enabling it without SMTP wedges admin login).
staffDeviceVerification: false

mail.secretName — Name of the prerequisite dictionary secret (keys user, password) created in Prerequisites. Empty keeps email fully off; set, it turns on Ghost’s SMTP transport and grants the Ghost identity reveal on exactly this secret. mail.host and mail.from are then required — the chart refuses to render without them.
mail.port / mail.secure — 587 with secure: false for STARTTLS (default), or 465 with secure: true for implicit TLS.
mail.from — The From address for outgoing mail, for example "Ghost <noreply@example.com>".
staffDeviceVerification — Ghost 6 emails staff a 6-digit code on every admin sign-in from a new device. It defaults to false here so /ghost stays reachable on a mail-less install; the chart refuses true while mail.secretName is empty. Set it to true once SMTP works.

The SMTP credentials are read when the container starts. After changing the secret’s value, force a redeployment of RELEASE_NAME-ghost so Ghost picks up the new credentials.

Access

publicAccess:
  enabled: true # HTTPS site via the canonical *.cpln.app endpoint

internalAccess:
  type: same-gvc # options: none, same-gvc, same-org, workload-list
  workloads: []  # only used when type is same-gvc or workload-list
  # workloads:
  #   - //gvc/GVC_NAME/workload/WORKLOAD_NAME

publicAccess.enabled — Serve the site and the /ghost admin over HTTPS on the auto-assigned *.cpln.app canonical endpoint (default). Set to false for an internal-only instance: Ghost then runs with the internal cpln.local URL from the Site URL table and is reachable only per internalAccess.
internalAccess.type — Which workloads can reach Ghost on port 2368 over the internal network:

Type	Description
`none`	No internal access.
`same-gvc`	Allow access from all workloads in the same GVC (default).
`same-org`	Allow access from all workloads in the same organization.
`workload-list`	Allow access only from workloads listed in `internalAccess.workloads`.

Backing Database

# Ghost supports ONLY MySQL 8 (not MySQL 9, not MariaDB) — image pinned to mysql:8.
mysql:
  image: mysql:8
  # BOTH SECRETS MUST EXIST BEFORE YOU INSTALL — the deployment waits silently on a
  # secret that does not exist. See Prerequisites for the exact commands.
  # `dictionary` secret with keys `username`, `password`, `database`: MySQL is
  # initialized with it on first boot, and Ghost connects with the same keys.
  credentialsSecretName: my-ghost-db-credentials
  # `opaque` secret (encoding: plain) holding the MySQL root password.
  rootPasswordSecretName: my-ghost-mysql-root-password
  resources:
    minCpu: 150m        # keep cpu:minCpu ratio under the platform's 4:1 (500/150 = 3.3:1)
    maxCpu: 500m
    minMemory: 256Mi
    maxMemory: 1024Mi
  volumeset:
    capacity: 10 # initial capacity in GiB (minimum is 10)
  internalAccess:
    type: same-gvc
  # Scheduled DB backups to object storage (off by default) — pass-through to the
  # mysql template's native backup. See README "Storage setup" for provider setup.
  backup:
    enabled: false
    image: ghcr.io/controlplane-com/backup-images/mysql-backup:1.0.0 # works with all MySQL versions
    schedule: "0 2 * * *" # daily at 2am UTC
    resources:
      cpu: 100m
      memory: 128Mi
    provider: aws # aws or gcp
    aws:
      bucket: my-backup-bucket
      region: us-east-1
      cloudAccountName: my-backup-cloudaccount
      policyName: my-backup-policy
      prefix: ghost/backups
    gcp:
      bucket: my-backup-bucket
      cloudAccountName: my-backup-cloudaccount
      prefix: ghost/backups

mysql.image — Pinned to mysql:8. Ghost supports only MySQL 8 — not MySQL 9 and not MariaDB. Do not change it.
mysql.credentialsSecretName / mysql.rootPasswordSecretName — The names of your two prerequisite database secrets (see Prerequisites): a dictionary with username, password and database, and an opaque secret with the root password. MySQL applies them on first boot; Ghost reads only the first. Both must exist before installing and must be two different secrets.
mysql.resources / mysql.volumeset.capacity — CPU and memory bounds and the initial data volume size in GiB (minimum 10). The reservation-to-limit ratio is tuned to the platform’s cap for stateful workloads; keep it when you raise the limits.
mysql.internalAccess.type — Which workloads can reach MySQL directly on port 3306, using the same four types as Ghost’s internalAccess.
mysql.backup.* — Scheduled dumps to S3 or GCS, off by default. See Backing Up for the bucket, Cloud Account and IAM setup.

MySQL applies the database secrets only on first startup, when the data directory is empty. Editing a secret after the initial deployment does not change the running database — change the password inside MySQL with ALTER USER first, then update the secret’s password key (cpln secret edit SECRET_NAME) and force a redeployment of RELEASE_NAME-mysql and RELEASE_NAME-ghost (a secret change is not picked up until the workloads redeploy). To fully reset, cpln helm uninstall RELEASE_NAME --gvc GVC_NAME (which deletes both volume sets and all data) and reinstall, or install under a new release name.

Connecting

What	Address	Notes
Public site	`https://CANONICAL_ENDPOINT`	Assigned automatically when `publicAccess.enabled: true`. Read it from `status.canonicalEndpoint` in `cpln workload get RELEASE_NAME-ghost --gvc GVC_NAME -o yaml`.
Admin panel	`https://CANONICAL_ENDPOINT/ghost`	Editor, settings, members and staff. The owner account is created here on first visit — see First Run.
Internal (same GVC)	`http://RELEASE_NAME-ghost.GVC_NAME.cpln.local:2368`	Subject to `internalAccess.type`. With public access on, Ghost redirects plain-HTTP requests to its HTTPS `url` unless the request carries `X-Forwarded-Proto: https`.
Database	`RELEASE_NAME-mysql.GVC_NAME.cpln.local:3306`	Subject to `mysql.internalAccess.type`. Credentials: the secret named by `mysql.credentialsSecretName` — `cpln secret reveal SECRET_NAME -o yaml` (keys `username`, `password`, `database`).

Verify the site is serving once the workload reports ready — the default theme answers 200 before any owner exists:

cpln workload get RELEASE_NAME-ghost --gvc GVC_NAME -o yaml   # status.canonicalEndpoint
curl -s -o /dev/null -w '%{http_code}\n' https://CANONICAL_ENDPOINT/

With publicAccess.enabled: false there is no canonical endpoint; reach port 2368 from another workload in the GVC, or from your machine with cpln port-forward RELEASE_NAME-ghost 2368:2368 --gvc GVC_NAME. Driving the /ghost admin through that tunnel has not been verified for this template — Ghost’s url is then the internal cpln.local address, and its admin checks requests against it.

First Run

Ghost ships no bootstrap credentials. The first visitor to /ghost creates the owner account.

Wait for both workloads to report ready

MySQL initializes first; Ghost runs its database migrations and starts serving. Ghost retries its database connection until MySQL is up, so early connection errors in its log during a first install are expected.

cpln workload get-deployments RELEASE_NAME-ghost --gvc GVC_NAME -o yaml

Open the admin and create the owner

Browse to https://CANONICAL_ENDPOINT/ghost and complete the setup form — site title, your name, email and password. Do this right after install: until the owner exists the site is public with the default theme and anyone who reaches /ghost can claim it.

Configure mail before inviting anyone

Staff invitations, member sign-in links and newsletters are delivered only by email. Configure Mail (SMTP) first, then set staffDeviceVerification: true if you want the emailed sign-in code on new devices.

Operations

Backing Up

Two things hold your data: the MySQL database (posts, pages, members, settings, staff accounts) and the content volume set (uploaded images, themes). A database dump does not include media. Scheduled database dumps are off by default. When mysql.backup.enabled: true, the RELEASE_NAME-mysql-backup cron workload runs mysqldump --databases of the database named in the database key of your mysql.credentialsSecretName secret on mysql.backup.schedule and uploads a gzipped archive named mysql-TIMESTAMP.sql.gz under mysql.backup.*.prefix in your bucket. Pick a mysql.backup.provider and complete the storage setup before enabling it:

AWS S3
Google Cloud Storage

Create a bucket

Create an S3 bucket. Set mysql.backup.aws.bucket and mysql.backup.aws.region to match.

Set up a Cloud Account

If you do not have one, create a Cloud Account for your AWS account. Set mysql.backup.aws.cloudAccountName to its name.

Create a bucket-scoped IAM policy

Create an IAM policy granting the required S3 actions on the bucket (replace YOUR_BUCKET_NAME), and set mysql.backup.aws.policyName to its name. The template attaches it to the MySQL identity:

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME" },
    { "Effect": "Allow", "Action": ["s3:PutObject", "s3:GetObject", "s3:DeleteObject"], "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*" }
  ]
}

Create a bucket

Create a GCS bucket. Set mysql.backup.gcp.bucket to its name.

Set up a Cloud Account

If you do not have one, create a Cloud Account for your GCP project and grant its service account Storage Object Admin (roles/storage.objectAdmin) on the bucket. Set mysql.backup.gcp.cloudAccountName to its name — the template binds that role on exactly that bucket.

Content volume. The RELEASE_NAME-ghost-vs volume set keeps a final snapshot for 7 days when it is deleted. Take a snapshot before a theme change or an upgrade:

cpln volumeset snapshot create RELEASE_NAME-ghost-vs --gvc GVC_NAME --snapshot-name before-upgrade
cpln volumeset snapshot get RELEASE_NAME-ghost-vs --gvc GVC_NAME

Ad-hoc dump without a bucket. mysqldump is in the mysql:8 image. Binary output through cpln workload exec is not byte-safe, so wrap the stream in base64 on both sides; the root password is already in the container’s environment:

cpln workload exec RELEASE_NAME-mysql --gvc GVC_NAME --container mysql --quiet -- \
  sh -c 'mysqldump -u root -p"$MYSQL_ROOT_PASSWORD" --single-transaction --set-gtid-purged=OFF --databases ghost | base64' \
  | base64 -d > ghost.sql

This ad-hoc command has not been run against a live install of this template — try it on a throwaway release before relying on it.

Restoring a Backup

This restore procedure was written against the chart’s configuration and the backup image’s dump format. It has not been exercised against a live install of this template — rehearse it on a throwaway release before you need it, and treat any step that errors as a stop.

Scheduled dumps are gzipped mysqldump --databases output of the database named in the database key of your mysql.credentialsSecretName secret, created with --set-gtid-purged=OFF, so the archive recreates the database itself (CREATE DATABASE and USE are embedded) and carries no GTID statement to strip. Download the archive from your bucket (aws s3 cp or gsutil cp), then stream it into the running MySQL through cpln workload exec. Stdin is off by default on exec, so pass --stdin, and base64-wrap the stream so nothing is altered in transit:

gunzip -c mysql-TIMESTAMP.sql.gz \
  | base64 \
  | cpln workload exec RELEASE_NAME-mysql --gvc GVC_NAME --container mysql --stdin -- \
      sh -c 'base64 -d | mysql -u root -p"$MYSQL_ROOT_PASSWORD"'

Then restart Ghost so it drops its in-memory settings and reads the restored database:

cpln workload force-redeployment RELEASE_NAME-ghost --gvc GVC_NAME

The dump restores posts, members, settings and staff accounts. Uploaded images and themes are on the content volume set, not in the database — restore those from a volume set snapshot (cpln volumeset snapshot restore has not been exercised for this template; check cpln volumeset snapshot restore --help) or re-upload them.

Upgrading from 1.0.0

Template version 1.1.0 renamed the Ghost resource ceiling from cpu / memory to maxCpu / maxMemory, because the block also exposes minCpu / minMemory and the bare names left it ambiguous which number was the limit. Rename the two keys in your values before upgrading:

resources:
  maxCpu: 500m
  maxMemory: 1024Mi
  minCpu: 250m
  minMemory: 512Mi

An upgrade that still carries the old names is refused at render and your running release is left untouched:

Error: ... ghost: resources.cpu was RENAMED to resources.maxCpu. A block exposing both a reservation
and a limit names the limit maxCpu/maxMemory, so the bare name is no longer read and would be silently
ignored. Rename it in your values.

Blocks that expose only a limit (mysql.backup.resources) keep the bare cpu / memory names.

Upgrading from 1.1.0

Template version 1.2.0 adds staffDeviceVerification (default false), which turns off the emailed sign-in code Ghost 6 requires on every new-device admin login. On a 1.1.0 install without SMTP that code could never be delivered and /ghost was unreachable from a new browser; after the upgrade admin login works without mail. If you have SMTP configured and want the check back, set staffDeviceVerification: true. The first cpln helm upgrade after an install can restart the bundled MySQL even when no database value changed, so run it during a quiet period.

Upgrading from 1.2.0

Template version 1.3.0 removed mysql.config (database name, user, password and root password): the database credentials are now the two prerequisite secrets under Prerequisites, the same ones the mysql template requires on its own. An upgrade that still carries mysql.config is refused at render, before anything changes; mysql.enablePhpMyAdmin is refused the same way, so remove it too. 1.2.0 created the secret RELEASE_NAME-mysql-config itself, and this upgrade deletes it. Create the new secrets under different names, holding the values your database was initialized with (not new ones, or Ghost and MySQL lose their login). Read the current values first:

cpln secret reveal RELEASE_NAME-mysql-config -o yaml

Then create the two secrets from them (user becomes username; rootPassword gets its own secret). Use your current user and database names too, not ghost, if you changed them:

cpln secret create-dictionary --name my-ghost-db-credentials \
  --entry username='YOUR_CURRENT_USER' --entry password='YOUR_CURRENT_PASSWORD' --entry database='YOUR_CURRENT_DATABASE'
printf '%s' 'YOUR_CURRENT_ROOT_PASSWORD' | cpln secret create-opaque --name my-ghost-mysql-root-password --encoding plain -f -

Upgrade with mysql.credentialsSecretName and mysql.rootPasswordSecretName set to those names, and mysql.config and mysql.enablePhpMyAdmin removed. The upgrade restarts MySQL and Ghost, so the site is briefly unavailable. The new version of a workload can wait for several minutes, with get-deployments reporting that it is not allowed to reveal the secret, while access to the new secrets propagates; the previous version keeps serving meanwhile, and it clears by itself.

Scaling and Availability

Ghost is single-replica by design and this template has no replicas knob: Ghost holds scheduler, job-queue and cache state in-process and has no upstream support for running more than one instance against the same database. Both workloads are pinned to one replica. Durability comes from the two volume sets and, optionally, scheduled database dumps. A restart or upgrade is a brief interruption of the one replica; put a CDN in front of a busy public site to absorb it. Raise resources.maxCpu / resources.maxMemory (and the mysql.resources counterparts, keeping the reservation ratio) to scale vertically.

Troubleshooting

Upgrade fails with resources.cpu was RENAMED to resources.maxCpu

Symptom: cpln helm upgrade from template version 1.0.0 stops at render with ghost: resources.cpu was RENAMED to resources.maxCpu (or the resources.memory equivalent). Nothing is changed on the platform.Cause: Your values still use the 1.0.0 key names.Fix: Rename resources.cpu to resources.maxCpu and resources.memory to resources.maxMemory, then upgrade again. See Upgrading from 1.0.0.

Render refused with staffDeviceVerification requires SMTP

Symptom: Install or upgrade fails with

ghost: staffDeviceVerification requires SMTP — set mail.secretName (Ghost emails the 2FA code) or leave staffDeviceVerification: false

.Cause: staffDeviceVerification: true with mail.secretName empty. Ghost would email a code it has no way to send, and admin login would never complete.Fix: Configure Mail (SMTP) first, or set staffDeviceVerification: false.

Symptom: Signing in at /ghost from a new browser prompts for a 6-digit code and no email arrives; the browser shows a server error on submit.Cause: You are on template version 1.1.0 or earlier without SMTP, or on 1.2.0 with staffDeviceVerification: true and a mail configuration that does not deliver.Fix: Upgrade to 1.2.0 (the default turns the check off) or fix the SMTP settings and credentials in mail.*; after changing the secret’s value, run cpln workload force-redeployment RELEASE_NAME-ghost --gvc GVC_NAME.

Ghost workload never becomes ready and cpln logs shows nothing

Symptom: RELEASE_NAME-ghost stays not ready after install with mail.secretName set, and cpln logs returns no lines for it.Cause: The SMTP secret named in mail.secretName does not exist, so the container never starts.Fix: Read status.versions[].message in cpln workload get-deployments RELEASE_NAME-ghost --gvc GVC_NAME -o yaml — it names the missing secret. Create it as shown in Prerequisites; the workload recovers on its own, or immediately after cpln workload force-redeployment RELEASE_NAME-ghost --gvc GVC_NAME.

Links and emails still point at the cpln.app address after adding a custom domain

Symptom: The site answers on your domain, but generated links, the RSS feed and emails use the *.cpln.app endpoint — or the admin reports access denied from url.Cause: publicUrl is empty (Ghost derived the canonical endpoint), or it was changed but the container has not restarted — the value lives in the startup-script secret, which is read only at container start.Fix: Set publicUrl to the full https:// address visitors use, upgrade the release, then run cpln workload force-redeployment RELEASE_NAME-ghost --gvc GVC_NAME.

Changed a database password in the secret but MySQL still uses the old one

Symptom: After editing the password key of your database credentials secret and redeploying, Ghost fails to authenticate with Access denied for user.Cause: MySQL applies the database secrets only when the data directory is first initialized. Ghost now sends a password the database never learned.Fix: Either change the password inside MySQL to match the new value (ALTER USER 'ghost'@'%' IDENTIFIED BY '...' via cpln workload exec RELEASE_NAME-mysql --gvc GVC_NAME --container mysql -- mysql -u root -p ...), or put the old value back in the secret and force a redeployment of RELEASE_NAME-ghost. A clean reset is uninstall (deletes both volume sets) and reinstall.

MySQL never becomes ready and cpln logs shows nothing

Symptom: RELEASE_NAME-mysql stays not ready after install, and cpln logs returns no lines for it.Cause: A secret named by mysql.credentialsSecretName or mysql.rootPasswordSecretName does not exist, so the container never starts.Fix: Read status.versions[].message in cpln workload get-deployments RELEASE_NAME-mysql --gvc GVC_NAME -o yaml — it names the missing secret. Create it as shown in Prerequisites; the workload recovers on its own, or immediately after cpln workload force-redeployment RELEASE_NAME-mysql --gvc GVC_NAME.

Upgrade fails with mysql.config was removed in 1.3.0

Symptom: cpln helm upgrade stops at render with ghost: mysql.config was removed in 1.3.0 (or mysql.enablePhpMyAdmin was removed in 1.3.0). Nothing is changed on the platform.Cause: Your values still carry the 1.2.0 plaintext database passwords.Fix: Create the two database secrets holding your current values and remove the old keys — see Upgrading from 1.2.0.

Important Notes

Create both database secrets before installing — a missing one wedges RELEASE_NAME-mysql silently; see Prerequisites.
The database secrets seed MySQL on first boot only — editing them later does not change the stored passwords: change the password inside MySQL first, then update the secret and force a redeployment of RELEASE_NAME-mysql and RELEASE_NAME-ghost.
Create the owner account right after install — until someone completes the form at /ghost, the public site has no admin and anyone who reaches it can claim ownership.
MySQL 8 only — keep mysql.image: mysql:8; Ghost does not support MySQL 9 or MariaDB.
SMTP is a prerequisite secret, not a value — create the dictionary secret (keys user, password) before installing with mail.secretName set; a missing secret wedges the deployment silently.
Set publicUrl when you attach a custom domain, then force a redeployment of RELEASE_NAME-ghost — links and emails use whatever url the container started with.
staffDeviceVerification: true requires working SMTP — the chart refuses it otherwise, and a mis-delivering mail setup locks staff out of /ghost from new devices.
Single replica by design — there is no replicas knob; expect a brief interruption on restart or upgrade, and the first upgrade after install can restart the bundled MySQL.
Data survives redeploys under the same release name — content in RELEASE_NAME-ghost-vs, the database in RELEASE_NAME-mysql-vs. cpln helm uninstall deletes both; a database dump does not include uploaded media.

External References

Ghost Documentation

Official Ghost product documentation

Configuration Reference

The url, mail and security options this template sets

Supported Databases

Why Ghost requires MySQL 8

Device Verification and Email 2FA

The staff sign-in code that staffDeviceVerification controls

Official Docker Image

The library/ghost image on Docker Hub

Ghost Template

View the source files, default values, and chart definition

Template Catalog

Templates

Overview

What Gets Created

Prerequisites

Installation

UI

CLI

Terraform

Pulumi

Configuration

Ghost Application

Site URL

Mail (SMTP)

Access

Backing Database

Connecting

First Run

Operations

Backing Up

Restoring a Backup

Upgrading from 1.0.0

Upgrading from 1.1.0

Upgrading from 1.2.0

Scaling and Availability

Troubleshooting

Important Notes

External References

Ghost Documentation

Configuration Reference

Supported Databases

Device Verification and Email 2FA

Official Docker Image

Ghost Template

​Overview

​What Gets Created

​Prerequisites

​Installation

UI

CLI

Terraform

Pulumi

​Configuration

​Ghost Application

​Site URL

​Mail (SMTP)

​Access

​Backing Database

​Connecting

​First Run

​Operations

​Backing Up

​Restoring a Backup

​Upgrading from 1.0.0

​Upgrading from 1.1.0

​Upgrading from 1.2.0

​Scaling and Availability

​Troubleshooting

​Important Notes

​External References

Ghost Documentation

Configuration Reference

Supported Databases

Device Verification and Email 2FA

Official Docker Image

Ghost Template

Overview

What Gets Created

Prerequisites

Installation

Configuration

Ghost Application

Site URL

Mail (SMTP)

Access

Backing Database

Connecting

First Run

Operations

Backing Up

Restoring a Backup

Upgrading from 1.0.0

Upgrading from 1.1.0

Upgrading from 1.2.0

Scaling and Availability

Troubleshooting

Important Notes

External References