Skip to content

Docs

Security and Capabilities Overview

An evaluation-level view of what the platform protects - member data, content, payments, and access - described as capabilities, not internals.

Last updated

This page is for evaluators who want to understand what Seedly Communities protects and how access is governed, before committing to run it. It describes capabilities - what the platform does - rather than implementation. Because you receive and own the full source, your own team can review the code in as much depth as you like. This page is the map, not the territory.


The Ownership Posture#

Security starts with where things run. Seedly Communities is source you own, deployed on infrastructure you control - the backend on your Convex Cloud account and the web app on your Vercel account. Member records, payments, and secrets live in accounts you hold, not in a shared multi-tenant service operated by a vendor. There is no third party sitting between you and your members' data, and no vendor access to your production instance you did not grant.


Access and Roles#

The platform governs who can do what through role-based access with four member roles, from ordinary members up to full administrators. Every meaningful action is checked against the acting member's role before it runs.

  • Enforced on the server. Permission decisions are made on the backend, not left to the interface. Hiding a button is a convenience for members, never the thing that actually protects an action.
  • Least privilege by default. Members can act on their own content and the areas their role grants. Elevated capabilities - moderation, billing, community settings - are reserved for the roles that should hold them.
  • No privilege climbing. The role system prevents a member from granting themselves or others access above what their own role allows.

Member Data Isolation#

Members see the community they belong to and the profile information other members have chosen to share, and nothing behind the scenes. Private data - direct messages, billing details, session notes, quiz and assignment submissions, moderation records - is scoped to the people entitled to it. Direct messaging honors each member's own privacy choice of who may contact them. A member cannot reach another member's private records by guessing or manipulating a request, because entitlement is verified on every read and write, not assumed from the interface.


Content Safety and Moderation#

Every community needs tools to keep discussion healthy, and those tools are built in.

  • Automated keyword filtering can hold or block content that matches lists you configure, before it reaches the feed.
  • Member reporting lets the community flag posts and comments with a reason, routing them to a review queue.
  • A moderation workflow gives admins one place to approve, reject, or take down flagged content.
  • Suspend and ban controls remove a bad actor's access, and that enforcement carries across every module rather than one screen.
  • A moderation audit trail records what action was taken and by whom.

Input Handling and Content Integrity#

All member-generated content - posts, comments, lesson text, chat, profiles - is treated as untrusted and cleaned before it is stored and shown, so one member cannot inject content that runs in another member's session. Incoming data is validated against what each operation expects, so malformed or unexpected input is rejected rather than acted on. These protections apply everywhere members can write, not just the obvious surfaces.


Spam and Abuse Controls#

The platform limits the pace of sensitive and automated actions to blunt abuse and automated hammering, and rejects malformed requests before they do work. Programmatic access through the developer API is authenticated per key and paced per key, so an integration - or a leaked key - cannot run unbounded against your community. Outbound webhooks are restricted to safe destinations.


Secure Payments#

Member payments run entirely through your own Stripe account. Card data is handled by Stripe's hosted, PCI-compliant payment surfaces - the community never sees or stores raw card numbers. Subscription state changes arrive as verified events from Stripe, so your community's record of who has access reflects what actually happened at the payment processor, and cannot be spoofed by a forged request. The platform adds 0% in transaction fees on top of Stripe's own pricing.


Secure Media Handling#

Uploaded files - images, course video, and live-event recordings - are validated on the way in and stored in a storage service under your own account. Access to private media is governed by the same entitlement rules as the rest of the platform, so a recording or an attachment meant for enrolled students is not reachable by someone outside that audience. Live video runs through a third-party real-time provider (Daily.co) connected with your own credentials.


Secrets and Configuration#

The keys that make the instance work - provider credentials, payment keys, and signing secrets - live in your environment configuration, never in the codebase and never exposed to members. You hold them, you rotate them, and losing control of them is within your power to prevent. Keeping them backed up and out of source control is covered in Backups and Data Ownership.


What Ownership Means for Security#

Owning the source cuts both ways, and it is worth being straight about it. You get complete transparency - nothing about how the platform protects data is hidden from you, and your team can audit every line. You also carry the operational duties that a hosted vendor would otherwise handle - keeping your deployments patched with new releases, guarding your secrets, and running your backups. The platform gives you strong protections out of the box, and keeping them strong over time is part of what you took on when you chose to own it.


Was this page helpful?