Docs
Core Concepts
The Seedly Sites mental model - tenants, the Section Row Column Element hierarchy, drafts vs published, and why Publish is not Deploy.
Last updated
Five ideas explain how Seedly Sites works. Everything else in these docs builds on them.
One Platform, Many Client Sites#
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 |
| Deploys | Yes - deploys are operator-controlled | No (unless you grant it) |
An agency record sits above tenants as the white-label parent: your logo and brand color on the client login experience, and a home for agency-wide defaults.
Section, Row, Column, Element#
Every page is a tree with a strict, predictable hierarchy:
- Section - a full-width horizontal band of the page. Sections stack top to bottom and own the background, the color style, and the vertical padding.
- Row - a layout inside a Section, chosen from presets (Whole, Halves, Thirds, and asymmetric splits).
- Column - one cell of a Row. Columns carry per-breakpoint widths, so a three-column desktop row can stack cleanly on phones.
- Element - the actual content inside a Column: Heading, Text, Image, Button, Grid, Accordion, FAQ, Map, and the rest of the element library.
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.
Pages and the Blog#
Tenants have two kinds of content:
- Pages are built in the visual builder as Section trees - the home page, services, about, contact, and so on. One page is designated the home page and serves at the site root.
- Blog posts are written in a rich-text editor with categories, tags, and author profiles, and rendered through a blog template you can edit in the builder.
Both support drafts and scheduled publishing. See Pages and Blog.
Drafts, Published, Live#
Content moves through three distinct states:
- Draft - saved work in progress. Visible in the CMS and preview, never on the live site.
- Published - marked as the live version in the CMS. This is what the next deploy will ship.
- Live - actually on the client's domain, after a deploy.
The gap between published and live is deliberate, which brings us to the rule that matters most.
Publish Is Not Deploy#
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:
- You can batch a week of edits across ten pages and ship them in one clean deploy.
- A client can safely edit all day without anything half-finished reaching their visitors.
- Every change to a live site happens at a moment you chose, with a readiness check in front of it.
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.
Where Things Run#
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.
Frequently asked questions
- What is a tenant in Seedly Sites?
- A tenant is one client site - its pages, blog, media, settings, users, and deploy pipeline, all scoped together. The operator manages every tenant from one login; a client user sees only their own.
- What is the difference between publishing and deploying?
- Publishing saves content as the live version inside the CMS. Deploying rebuilds the static site and pushes it to hosting. Nothing a client sees changes until you deploy - deploys are always a manual, operator-controlled step.
- If a client edits their site, when do visitors see the change?
- When the operator next deploys that site. Client edits (and scheduled publishes) update the CMS content, and the live static site updates on the next deploy.
- How are pages structured in the builder?
- Every page is a tree - Sections stack down the page, each Section holds Rows, each Row holds Columns, and Columns hold the actual elements like headings, text, images, and buttons.