Security
Security at the deck operation boundary
DeckStera treats every deck read and write as an authorized organization operation. Passwords and service secrets are stored as one-way verifiers, browser mutations require CSRF protection, remote API access is scoped and expiring, and PostgreSQL tenant context reinforces application checks. Draft changes never become public merely because they were saved.
- Opening
- Evidence
- Offer
- Next step
Designed as a system
Make the story durable, not just the file
Layered tenant controls
Application authorization and database policies share an explicit organization context.
Secret-safe credentials
Recovery, verification, invitation, session, and service tokens are persisted as verifiers.
Publish deliberately
A reviewed immutable release is distinct from the current working revision.
From intent to delivery
A governed path through every revision
- 01
Structure the narrative
Start with a brief, a reusable pattern, or an existing DeckSpec.
- 02
Edit through semantic operations
Use the visual builder, HTTP, or MCP without splitting the document model.
- 03
Review and deliver
Resolve diagnostics and proposals before compiling the approved revision.
Direct answers
Frequently asked questions
How does DeckStera isolate organization data?
DeckStera requires organization context at authorization, repository, command, query, and credential boundaries. PostgreSQL row-level policies add a second tenant-isolation layer for the customer runtime.
Are drafts published automatically?
No. Saving or generating a draft does not expose it publicly. Publishing creates a separate immutable release, and access mode, indexing policy, custom-domain verification, and review state are applied deliberately.
Ready when the story matters