Could Ghost run on Laravel Cloud?

Ghost is the sort of application we want Scalpels to make easy to own. It is a complete publishing platform with posts, memberships, newsletters, and a social web. It is maintained as open-source software, not assembled from Laravel packages. It is also a Node application with its own assumptions about servers, storage, and first-time setup.

Could it belong in the Scalpels marketplace anyway? Before building anything, we read Ghost's source, its published npm package, the official Docker setup, and the hosting documentation. We came away thinking a small wrapper was the most promising approach, and with several predictions to test.

Package the release, not the monorepo

Ghost's source repository is a pnpm and Nx monorepo. Its production image gets a prebuilt admin application from Ghost's own release process, so building the repository directly on Cloud is a poor starting point. The published ghost npm package already includes those assets and runs with Node. We expect the install to unpack and run that release instead.

That would make the marketplace source a wrapper, not a clean fork of Ghost. We need to learn how small that wrapper can stay and whether updates can stay routine.

Mail has to work on day one

Ghost members sign in through emailed magic links. Staff device verification is on by default in production, and password resets and invitations also use email. A deployment without working transactional mail can lock out the owner as well as members.

Cloud can attach a Resend email resource to an application. Ghost sends transactional mail over SMTP. We expect the wrapper to translate the mail environment variables Cloud sets into Ghost's nested configuration. Newsletters are a separate question, because Ghost uses Mailgun for bulk delivery.

Persistent files do not all use the same path

Ghost has an S3 adapter for images, media, and files. Themes are different. An uploaded theme lives under content/themes on local disk, and Cloud replaces the local filesystem on every deployment. We expect ordinary uploads to fit a public bucket. We expect an admin-uploaded theme to disappear on a deploy or restart unless we put it in the repository or find another way to keep it.

Cloud buckets also delete .html and .htm uploads. Ghost permits those as file attachments, so that edge case needs an answer even if normal pages and theme archives are unaffected.

The configuration needs translating

Cloud provides a MySQL connection URL in an environment variable. Ghost expects separate host, port, user, password, and database values. Cloud also supplies a public application URL and a port to listen on. Ghost uses different names for both, and by default it listens on an address Cloud cannot reach. Bucket and mail settings need the same kind of mapping. A boot script should be able to do the translation, but the experiment has to prove it.

We expect one MySQL-backed instance with no autoscaling. Ghost keeps settings, scheduled work, and background jobs in the web process. If we ran more than one replica, or copy of the application, they could disagree or run work twice. Cloud can also hibernate an idle application, which may delay scheduled posts by freezing their in-process timers.

First boot and the edge

A fresh Ghost install leaves owner setup open to whoever visits first. A marketplace install cannot leave that open. We expect to create the first owner through Ghost's setup endpoint before opening public access. That also tests something Scalpels cannot do yet, which is make a one-time HTTP call after the first deployment.

Cloud's edge, the layer that handles requests before they reach the application, raises more questions. Ghost's admin previews the public site in a frame, but Cloud's default frame policy is stricter. Ghost's social-web routes include dot-prefixed paths and normally sit behind a path-aware reverse proxy. Scheduled publishing calls back into Ghost through its public URL. We need to know which of those requests Cloud accepts and which settings or proxy work they require.

So the experiment is less about whether a Node process can boot. It has to show that one owner can safely take control, publish and schedule posts, upload files and a theme, sign in through email, and use Ghost's integrations after another deployment. Then we can decide whether the wrapper and the remaining platform gaps are small enough for a marketplace listing.