Beta . Ortha CMS is in public beta. Every plan is free until it ends.
Get started
Menu

Governance · 13 / 23

Segments

Decide who may read a published entry. Each audience can see it, cannot see it, or is left unset — and cannot see always wins.

Content Articles The quiet return of night trains EN· English Published · up to date
Content Access History
The quiet return of night trains
Published EN · English Published Oct 23, 2026 Saved 3 minutes ago
Readable by everyone Audiences left on “Not set” follow the default: everyone can read.
Search audiences Set all… Manage segments
Audience Tags Access
Subscribers Tags: plan.paid
Staff Tags: staff
Partners Tags: partner

Access is saved with the entry and applies to every language of the record, not to this translation alone.

Who reads it
  • A reader with no tags Can read Cannot read
  • Tagged plan.paid Can read Cannot read
  • Tagged partner Can read Cannot read
  • Tagged staff, partner Can read Cannot read

The same rule on REST, GraphQL and MCP, for every language of the entry.

How it works

  1. 01

    Create audiences matched by the tags your readers arrive with.

  2. 02

    Set each audience on an entry’s Access tab.

  3. 03

    REST, GraphQL and MCP enforce the same rule.

Per audience
Not set, Can see, Cannot see
Precedence
Cannot see wins
Scope
Every language of the record

In depth · For teams with gated or tiered content

Live, but only for its readers

Gate a members’ area, per-customer docs or a regional launch: an entry can be published and still readable only by the people it is for.

Three rules

A segment is a named set of tags. An entry has an allow list and a deny list; a reader arrives with tags. Deny always wins, an empty allow list means unrestricted, otherwise the reader must match it.

Under the hood

The check runs inside the query the reader was already making. With no segment created it is never emitted, so turning the feature on changes nothing.

A grid of four entries against three kinds of reader, showing which combinations can read. An entry with no lists is readable by all three; adding an allow list closes it to everyone not named in it; a deny list removes a reader an allow list would otherwise have admitted.
Entry AnonymousMemberStaff
No lists set Yes Yes Yes
Allow: members No Yes No
Allow: members, staff No Yes Yes
Allow: members · Deny: staff No Yes No
Deny always wins.

You decide where tags come from

Ortha does not authenticate your readers. You give it one function that reads the request — a JWT claim, a CDN header, your billing system — and returns tags. Without it every reader is anonymous, and restricted content does not serve.

Done for you

Every relation hop is checked
On REST expansion, GraphQL nested resolvers and agent tools alike.
Counts do not leak
A restricted target is missing from both the items and the total.
Versioned with the words
Restoring an old version also restores who could read it.
Same for every translation
Access is written to the whole locale group at once.
Editors see it, admins set it
Contributors and viewers can read an entry’s segments; changing them needs segments:manage.

Questions

How many segments can I have?

Unlimited during the beta. After 1.0, three on Community and unlimited on a plan; most installations need one or two.

Does this give me a login for my readers?

No. You map readers to tags however you already identify them, in one function.

Does it slow down public reads?

Only where there is something to check: a primary-key probe and two indexed array intersections, inside the same query.

Full reference in the docs