Multi-tenant SaaS — public Hugo website + SMS CRM for American Legion posts, provisioned from a single YAML spec
Legion Post Platform is a multi-tenant SaaS that gives American Legion posts a fast, accessible public website and a built-in SMS reminder CRM — provisioned from a single YAML spec. Each post gets its own isolated environment: a Hugo static site on a custom domain, a containerized Go CRM backed by SQLite, and a dedicated Twilio number for member communications. The platform targets the ~12,000 U.S. Legion posts currently underserved by dated, expensive site vendors.
The CRM and website are tightly integrated: officers, event schedules, photo galleries, roster, and prose pages are all authored in the CRM and served to the public site through JSON APIs consumed at build time. Posts manage their entire web presence through the CRM's self-service dashboard — no technical knowledge required.
A lean, single-binary CRM paired with Hugo static sites — every tenant isolated at the process boundary, not behind a shared database flag.
Multi-tenancy is enforced at the process boundary, not with a tenant_id column. Each post runs its own Docker container drawn from a shared GHCR image, with its own named-volume SQLite database, secrets file, Caddy block, and Twilio subaccount. A one-call provision CLI reads a client YAML spec and emits the full per-tenant environment — Hugo config, CRM container compose, Caddy routes, and an admin password — leaving a CHECKLIST.md for the remaining manual steps.
A complete platform: provisioning tooling, a self-service CRM, TCPA-regulated messaging, and subscription billing.
provision CLI call from a client YAML specbilling CLI manages plans and generates Square-hosted checkout linksPublic-facing screens captured from the live platform. Admin dashboard screenshots pending Darrell's login credentials.
Public onboarding wizard — intake form for a new post
Staging preview of Post 5's public Hugo-built website
The engineering decisions that make this a maintainable, scalable multi-tenant platform rather than a collection of one-off deployments.
The Go CRM compiles to a single ~38 MB binary with all templates, database migrations, and static assets embedded at compile time using Go's embed package. The runtime artifact is one binary plus one SQLite file — no CGO, using modernc.org/sqlite. Deployments are a container pull and restart.
There is no tenant_id column and no shared database. Each post runs its own Docker container from a shared GHCR image, with a dedicated named-volume SQLite DB, secrets file, Caddy block, and Twilio subaccount. A misconfigured row cannot leak data between posts because their processes never share memory or disk.
No session table and no Redis. Session state is carried in an HMAC-signed cookie validated on every request — the CRM stays stateless-friendly while remaining secure, with no external cache dependency to operate or scale.
The CRM exposes public endpoints (/api/gallery.json, /events/events.json, etc.) that Hugo consumes at build time. An officer edits content in the CRM; the CI/CD pipeline (push-to-main → rsync) rebuilds and deploys the static site without any further manual step.
Members enroll through a double opt-in SMS flow. All standard opt-out keywords (STOP, UNSUBSCRIBE, CANCEL, END, QUIT) are honored immediately via Twilio webhook. Every inbound and outbound message — including opt-out confirmations — is audit-logged, giving each post a complete, time-stamped message record.
GitHub Actions publishes the CRM image to GHCR on every push to main — tagged latest plus sha-<short> and semver on git tags. The static Hugo site deploys via rsync on push. The full pipeline was operational from the first tenant deployment, not retrofitted later.
Scoping, architecting, and shipping a multi-tenant SaaS from the ground up — not just a website, but a complete platform.
Legion Post Platform shows what it looks like when we scope and ship a multi-tenant SaaS end to end — provisioning tooling, a production Go backend, TCPA-regulated messaging, and a billing integration. If you have a product idea that needs the same treatment, let's talk.
Go 1.23 (single binary, embedded assets, stdlib net/http), Hugo for per-post static public sites, SQLite via modernc.org/sqlite (no CGO), Docker, Caddy, Twilio, and Square — self-hosted on an HTS VPS.
Each Legion post runs its own Docker container from a shared GHCR image, with a dedicated named-volume SQLite database, secrets file, Caddy block, and Twilio subaccount. There is no shared database and no tenant_id column — isolation is enforced at the process boundary.
Yes — multi-tenant architecture, provisioning tooling, and Go backends are within our scope. See our software development service to start a project.
Tell us what you have in mind and we'll come back with an approach and a flat quote — no obligation.