How to Use SiteSolide: The Beginner's Guide to One-Command Deploys

How to Use SiteSolide: The Beginner's Guide to One-Command Deploys

This how to use sitesolide tutorial is about SiteSolide, the one-command deploy tool from Clément Thiriet (sitesolide.fr, GitHub @cthiriet) — not Slido the meeting app, not SolidJS the JavaScript framework, not SolidOS, and not the medicines your search engine keeps suggesting. It is for anyone who has built an app with an AI coding agent — Claude Code, Cursor, Codex — and now wants it live on their own server, with its own HTTPS address, without signing up for another platform and without learning Docker.

SiteSolide's whole idea fits in one sentence, from the vendor's own homepage: "Deploy your vibe-coded apps on your own server: one command per app, each with HTTPS and its own address, apart from the others, open to whoever you choose." The deploy command is the product — you do not rent a platform, you point a command at your own Debian 13 server and the app is live. This guide walks the full beginner arc: the mental-model lesson, your first deploy, the HTTPS and custom-domain lesson, the redeploy loop you will actually live in, an honest comparison with the alternatives, and the seven mistakes beginners make. It launched on Product Hunt on October 29, 2026, and every fact here was checked against the vendor's pages on November 3, 2026.

What Is SiteSolide, Exactly?

SiteSolide is a free, open-source (MIT) command-line tool that deploys apps to your own server — one command per app, each app isolated, each with HTTPS. The vendor's pitch is the sitesolide deploy command itself: you run it inside your project folder and the app is live at its own address, on your own machine, where you pay only for the server.

Under the hood there is no Docker. The stack is Caddy (reverse proxy + automatic HTTPS), systemd services (one sandboxed service per app, each under its own user), and restic (hourly backups, offsite when you configure an S3 or B2 bucket). The CLI is a single executable — the vendor's own line is "no Bun and no clone." If you are still deciding what server to run all this on, read our what is VPS hosting guide first — SiteSolide assumes you have a server you control.

What Does "One Command per App" Actually Mean?

It means the deploy command is the interface, not a dashboard you rent. Here is the whole three-command arc from the vendor's homepage, and what each command actually does:

If you searched "deploy vibe coded app to own server," this is the tool that search is describing. The mental-model lesson: a platform sells you hosting and takes a margin on it; SiteSolide sells you nothing. There is no paid tier — the Product Hunt listing says 0 USD, the site says free and open source, and the price you pay is the server plus a domain. That also means the guarantees of a platform are yours to own: the vendor is honest about the tradeoffs, and they are listed later in this guide.

How Do You Deploy Your First App With SiteSolide?

You install one executable, point it at your server, and run the deploy command from your project folder. The whole first deploy is three steps:

1. Install the CLI. The vendor's homepage gives curl -fsSL https://sitesolide.fr/install.sh | sh. The GitHub README instead documents curl -fsSL https://github.com/cthiriet/sitesolide/releases/latest/download/install.sh | sh. Both were fetched on November 3, 2026; they may be equivalent endpoints, and the vendor does not say — pick the one from the page you trust and check it before running it.
2. Run sitesolide setup. This prepares a Debian 13 server reachable over SSH — your own machine, or one the command orders from Hetzner, DigitalOcean, AWS, Google Cloud, Azure, Vultr, Akamai (Linode), or Scaleway — hardens it, and arranges DNS. You need your own domain at any registrar.
3. Deploy from the project folder. cd your-project && sitesolide deploy. Your app goes live at https://your-project.example.com — HTTPS included, no manual certificate work.

Two constraints decide whether step 3 works. First, the server must be Debian 13 — that is the only OS the vendor supports, and setup expects it. Second, your app must listen on a port: SiteSolide supports Bun, Node, Python, Go, Ruby, any binary, and static sites — "anything that listens on a port," per the vendor. The examples the author measured are a Next.js wiki on SQLite, a Django CRM on PostgreSQL, and Astro static docs. If your app needs a database, run it on the server yourself — the vendor's Django example uses PostgreSQL, but SiteSolide does not provision it for you.

How Does SiteSolide Give You HTTPS and a Custom Domain?

Every app gets an address like <project>.<zone>, and Caddy issues the certificate automatically. If your query was "sitesolide setup https custom domain," this section is the whole answer: DNS is the only part you have to think about, and SiteSolide handles it two ways — at providers with an API it creates the records itself (Cloudflare, Route 53, DigitalOcean, Hetzner, Azure, Gandi, Akamai, OVH, Porkbun, Scaleway, Vultr), and everywhere else it lists the records for you to create manually.

Your own domain works as soon as its DNS points at your machine — including bare domains and the www.-to-bare redirect, both supported since v0.14.0. The rule that bites beginners: point the DNS first, deploy second. The HTTPS certificate can only be issued for a name that already resolves to your server, so deploying before the DNS propagates is the classic way to get a broken first deploy. After any deploy, run your address through an SSL certificate checker to confirm the certificate is valid and the chain is complete.

How Do You Redeploy When You Change the Code?

You run the same command again: sitesolide deploy builds the new code, restarts the service, and checks the app answers on HTTPS. The update loop is push code, deploy, verify — the loop every beginner lives in, and the reason the command is the product.

Two honest details from the vendor change how you treat that loop. There are no zero-downtime deploys: a deploy restarts the service, and a visitor gets a 502 until the new process is listening, so you schedule deploys instead of promising seamless ones. And rollback is not a button — you roll back by deploying the previous commit. That makes committing before every deploy a discipline, not a nicety: our Git beginner guide covers the commit habits that make this safe, and if you deploy from a repository, our GitHub beginner guide walks the push workflow the redeploy loop assumes.

How Does SiteSolide Compare to Vercel, Coolify, and Kamal?

This is the sitesolide vs coolify decision most beginners face, and the vendor publishes its own comparison table on sitesolide.fr — restated here exactly as they present it. It is the vendor's framing, checked against each project's own site and docs on October 5, 2026, with the vendor's own invitation: "Out of date? Open an issue."

The "no Docker needed" row is the real fork in the road. If you already live in containers, our Docker beginner guide still applies to everything else you run — but on a SiteSolide server there is no container runtime at all. The vendor's memory numbers explain the bet: running 30 apps as systemd services measured 100 MiB per app, versus 130 MiB in Docker and 583 MiB in Firecracker micro-VMs — that benchmark is the vendor's own measurement, published October 28, 2026, and you should treat it as a vendor claim, not an independent test.

The vendor also ships a "What it does not do" list, and it is refreshingly blunt: no zero-downtime deploys; no failover — it is one machine; backups stay on the server until you add an S3 or B2 bucket; kernel reboots are yours. Read that list as the price of the one-command simplicity: you own the server, so you own the server's problems.

What Runs on the Server, Exactly?

Each app runs as a sandboxed systemd service under its own user, fronted by Caddy, with hourly restic backups and per-minute uptime monitoring. Alerts go to Slack, Discord, Google Chat, or ntfy. Company sign-in is any OpenID Connect provider — Google Workspace, Microsoft Entra, Okta — and secrets live server-side, never in your git repo. Scheduled workers are declared in a sitesolide.json file in your project.

The SSH model is the part to get right on day one: only the owner holds SSH access. Colleagues and coding agents deploy with personal, scoped, revocable tokens — nobody else gets a shell. That is the answer to "can my AI agent deploy for me": yes, with a token you can revoke, not your private key. An MCP server is included for Claude Code, Cursor, and Codex users — the agents the vendor explicitly targets. Note the gap the queue flagged: Lovable, v0, and Bolt are not named as supported outputs anywhere in the vendor's docs, so do not assume a one-click flow from them.

How Much Does SiteSolide Cost?

SiteSolide itself is free — MIT open source, no paid tiers, and the vendor says "you pay only for the server." The Product Hunt launch lists 0 USD and adds that you pay for the server and a domain. Your bill is the VPS from Hetzner, DigitalOcean, or your provider of choice, plus the domain registration.

The project is young and moving fast: the repository (github.com/cthiriet/sitesolide, created September 26, 2026) had 445 commits, 30 releases, 9 stars, and 2 forks at this run's fetch, and v0.16.0 landed on November 2, 2026 — one day before this guide. That release removed the dashboard's Audience section and its analytics service, so the vendor now tells you to bring your own analytics. On a project this young, verify the current release before you install.

What Are the 7 Beginner Mistakes With SiteSolide?

Sources

Every fact in this guide was checked against a page fetched on November 3, 2026. The three-command flow, the "one command per app" tagline, the setup's server-ordering providers, the DNS-provider list, the no-Docker stack, and the vendor comparison table come from the vendor's own site at sitesolide.fr (all vendor claims, quoted where the site gives exact wording). The install commands come from the sitesolide.fr homepage and the GitHub README at github.com/cthiriet/sitesolide — they differ, and this guide reports both as fetched without merging them. The SSH/token model, the systemd sandboxing, and the release history come from the README and the releases page, where v0.16.0 was confirmed as released November 2, 2026. The 100/130/583 MiB memory benchmark is the vendor's own measurement from the October 28, 2026 blog post "30 apps on one server" by Clément Thiriet — treated here as a vendor claim. The launch date — October 29, 2026 — the tagline "Deploy your vibe-coded apps on your own server," and the maker's "one person's project" comment come from SiteSolide's Product Hunt launch page; upvote and rating counts were not visible in this run's fetch, so none are stated. Repository statistics (created September 26, 2026; 445 commits; 30 releases; 9 stars; 2 forks) are as fetched this run and will have changed since.

Frequently Asked Questions

Is SiteSolide free?

Yes. SiteSolide is MIT open source with no paid tiers — the vendor's line is "you pay only for the server." Your actual bill is the VPS from a provider like Hetzner or DigitalOcean plus your domain registration.

Do I need Docker to use SiteSolide?

No — that is the product's central bet. The server stack is Caddy plus systemd services plus restic backups; there is no container runtime. Your app just needs to listen on a port: Bun, Node, Python, Go, Ruby, any binary, or a static site.

How is SiteSolide different from Coolify?

Coolify requires Docker and runs its own management platform on your server; SiteSolide needs no Docker and deploys each app as a sandboxed systemd service under its own user. Per the vendor's own comparison, both are free and self-hosted on your server — the difference is Docker-or-not and the one-command-per-app interface.

Can my team or my coding agent deploy without SSH access?

Yes. Only the owner holds SSH; colleagues and agents get personal, scoped, revocable tokens for deploying. An MCP server is included for Claude Code, Cursor, and Codex users.

What happens to my app during a redeploy?

The service restarts and a visitor gets a 502 until the new process is listening — SiteSolide does not do zero-downtime deploys, per the vendor. Rollback means deploying the previous commit, which is why committing before every deploy matters.