Documentation

Deploying Sites

Once the site builder has compiled your content into HTML, deployment is the last step — getting that HTML onto a public URL. SleekCMS gives you a few ways to do this without leaving the CMS: deploy directly to Netlify or surge.sh, download the built site as a ZIP and host anywhere, or push to your own pipeline by triggering an external build via a publish trigger.

This page covers the overall deploy model, the supported targets, and how to choose between them.

The Deploy Model

Every deploy starts the same way: the builder takes the current state of your content and templates, compiles them into a complete static site (HTML files, CSS, JS, images, assets), and then pushes that output to a destination. The build is fully contained — there's no external runtime, no server-side rendering, no database lookups on the deployed site. The deployed output is just files.

Because the output is pure static files, you can host it almost anywhere. SleekCMS supports two first-party push targets (Netlify and surge.sh) and a downloadable ZIP that works with every other static host on the planet.

Beyond the static site: If your frontend is built outside SleekCMS — a Next.js app, an Astro site, a mobile app — the deploy story is different. The build happens in your repo, and SleekCMS notifies it when content changes via a publish trigger. The output isn't a SleekCMS-built static site; it's whatever your own build produces.

Supported Push Targets

Netlify

A first-class integration. You authenticate SleekCMS with your Netlify account, choose a site, and every deploy from the CMS pushes the built output to that Netlify site. The result is live on your Netlify URL within seconds.

Netlify also gives you custom domains, HTTPS, edge caching, and redirects out of the box — managed in the Netlify dashboard.

→ Deploy site via Netlify

surge.sh

A lightweight target for quick deploys and shareable URLs. Surge serves your site under a *.surge.sh subdomain (or your own custom domain). The setup is minimal — no account configuration, no project linking.

Surge is a good fit for prototypes, internal demos, and any site where you want a free, fast public URL without setting up a host.

→ Deploy site via surge.sh

Download as ZIP

Click the download option and the CMS builds a fresh copy of the site, packages every file as a ZIP, and hands you the archive. From there you can upload it to any static host — Cloudflare Pages, Vercel, AWS S3 + CloudFront, GitHub Pages, your own server, anywhere.

This is the universal escape hatch. If a host accepts a folder of static files, the ZIP works.

→ Static Site Downloads

Triggers for External Builds

When your frontend lives outside SleekCMS — a Next.js app on Vercel, an Astro site on Cloudflare Pages, anything that builds in your own pipeline — deploys aren't initiated from the SleekCMS deploy section. Instead, you wire up a publish trigger that calls your external build system whenever content changes.

The pattern:

  1. Editor publishes content in SleekCMS.
  2. SleekCMS fires the configured trigger (a GitHub Actions workflow dispatch, a Netlify build hook, a custom webhook).
  3. The external system pulls fresh content from the SleekCMS API and rebuilds the site.

This is what you'd reach for if your codebase is the source of truth and SleekCMS is just the headless content layer. The deploy section is for sites built by SleekCMS; triggers are for sites built with SleekCMS content.

→ Automating using Triggers → Content API

Choosing a Deploy Target

Goal Use
Production site hosted on Netlify Netlify
Quick public preview / prototype surge.sh
Host on Cloudflare Pages, Vercel, S3, GitHub Pages, custom server Download as ZIP
Frontend lives in your own repo (Next.js, Astro, etc.) Publish triggers

Most sites use one of the first three for their production environment and download the ZIP occasionally for archiving or for offline review.

What's in the Deployed Output

Every deploy contains:

  • One HTML file per page record (static pages and collection items).
  • Compiled CSS — Tailwind output (if tailwind.css exists) plus any other stylesheets in css/.
  • All JavaScript files in js/.
  • All files in public/ (favicons, fonts, downloadables) at their original paths.
  • All images referenced from content, served from the image CDN (not copied into the output).

Images are not bundled into the deployed output — they stay on the SleekCMS image CDN. This keeps deployments small and gives you the on-the-fly transformation capability documented in Image Management. The deployed HTML references images via their CDN URLs.

The same is true for hosted videos and uploaded files — they live on their respective CDNs and are referenced by URL.

Cache and Invalidation

Deploys produce fresh files every time. Cache invalidation is the host's responsibility:

  • Netlify invalidates cached pages on every deploy automatically.
  • surge.sh serves the latest deploy with minimal caching.
  • Custom hosts (from a ZIP) follow whatever cache policy you've configured on that host.

For sites consumed via the API rather than the deploy step, see Environments & Content Versions for the equivalent invalidation mechanics on the content side.

What's Next