The Seedly Sites mental model - tenants, the Section Row Column Element hierarchy, the three ways to build a site, drafts vs published, and why Publish is not Deploy.
Loading the guide...
Help us make the guides more useful.
0 helpful · 0 not helpful
A few core ideas explain how Seedly Sites works. Everything else in these docs builds on them.
A Seedly Sites instance is a multi-tenant platform. Each client website is a tenant: its own pages, blog posts, media library, redirects, settings, custom domain, users, and deploy pipeline, strictly separated from every other tenant.
You, the operator, manage all of them from one login. An invited client logs in and sees only their own site. This is the split the whole product is designed around:
| Operator (you) | Invited client | |
|---|---|---|
| Sees | Every tenant | Only their own site |
| Builds and edits | Any site | Their own pages and posts |
| Configures | Branding, SEO, domains, users, billing | Their content, plus site settings if you give them the Administrator role |
| Deploys | Yes, always | Only if their login has Can deploy this site switched on, which it is by default when you create the login |
Your own white-label identity sits above all of this: the name, logo, accent color, and email From address your clients see on intake pages and in the emails the platform sends them are set once for the whole instance, under Branding in the operator sidebar.
Every page is a tree with a strict, predictable hierarchy:
The builder enforces this hierarchy, which is what keeps pages portable, consistent, and easy to restyle. Style lives in each element's native fields (size, color, alignment, spacing), not in hand-written CSS, so brand changes propagate cleanly. See Builder basics.
You never start a client site from a blank page unless you want to. There are three ways to fill a new site, and all three land as drafts for you to review:
Whichever you pick, the result is native builder pages you own and edit, and nothing publishes or deploys until you say so.
Tenants have two kinds of content:
Both support drafts and scheduled publishing. See Pages and Blog.
Content moves through three distinct states:
The gap between published and live is deliberate, which brings us to the rule that matters most.
Publishing saves content. Deploying ships it. Deploys are always manual.
When you (or a client) publish a page, the CMS records it as the live version - but the client's actual website is a set of static files on Cloudflare Pages, and those files do not change until you press Deploy in the portal. There is no automatic deploy on publish. A scheduled publish flips the content's status at the scheduled time; the site still updates on your next deploy.
This is the number one thing new operators trip on, and it is there by design:
One deliberate exception: a Reviews element set to Connected refreshes its reviews on its own once the page carrying it has been deployed. See Auto-Updating Review Widgets.
The deploy itself rebuilds the site as static files, regenerates the sitemap, robots rules, and redirects, and pushes the result to that tenant's Cloudflare Pages project. See Preview vs Publish vs Deploy and Deploying.
The CMS and builder run on your app host (Railway). Published sites are static files on Cloudflare Pages, one project per tenant, each on its own custom domain, with media served from R2 storage. The full picture, including why static output makes client sites fast, is on the Architecture page.
Next: skim the Feature Overview, then go build something in the visual builder.