Hosting Sveltia CMS under /admin on a static site – asset path limitation?

[JakobDrasch]

Hi 👋,

I’d like to share an observation when running Sveltia CMS under a subpath (/admin) on a static site, and ask whether this behavior is expected or a known limitation.

---

Setup (context)

• Framework: Astro (static / SSG)
• Hosting: IONOS (Apache, FTP deployment)
• CMS: Sveltia CMS
• CMS path: /admin
• Auth: GitHub OAuth via Cloudflare Worker
• Images location: /images/uploads
• Content: Markdown files under src/content/*

Folder structure (simplified):

/
├─ index.html
├─ admin/
│  └─ index.html   (Sveltia CMS)
├─ images/
│  └─ uploads/
│     └─ galerie_1.png

CMS configuration (admin/config.yml):

media_folder: "public/images/uploads"
public_folder: "/images/uploads"

editor:
  preview: false

---

Observation

• Images exist and are committed correctly
• Images load fine on the public site, e.g.:

https://example.com/images/uploads/galerie_1.png

• Inside the CMS UI, however, the browser tries to load:

/admin/#/assets/images/uploads/galerie_1.png

As a result:

• Image entries appear in the media library
• Previews are empty
• No explicit error is shown in the CMS UI

(Website rendering itself works as expected.)

---

Question / discussion point

Is this behavior expected when Sveltia CMS is hosted under a subpath (/admin) on static hosting?

More specifically:

• Is subpath hosting officially supported?
• Is there a recommended approach for asset handling in this scenario?
• Or is hosting the CMS at the site root (/) effectively required?

I’m not looking for hosting-specific support, just trying to understand the intended constraints and best practices around subpath usage.

Thanks for the great project!

[kyoshino]

Did you solve the issue yourself?

[JakobDrasch]

I was able to fix the issue.

Initially, in config.yml for the admin page, I set the base URL to:

https://admin.mysite.com

In IONOS, I created a DNS record pointing admin.mysite.com to the Cloudflare Worker dev URL that runs sveltia-cms-auth.

However, this setup didn’t work. It only started working after I changed the base URL in config.yml to point directly to the Cloudflare Worker URL (e.g. https://<worker-name>.<account>.workers.dev) instead of the custom domain.

So even though the DNS record resolved correctly, using the custom domain as the base URL caused issues, while using the Worker URL directly worked as expected.