An evaluation-level view of what the platform protects - member data, content, payments, and access - described as capabilities, not internals.
Loading the guide...
Help us make the guides more useful.
0 helpful · 0 not helpful
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.
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.
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.
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.
Every community needs tools to keep discussion healthy, and those tools are built in.
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.
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.
Since v2.2.0 the sign-in rate limit and, if you use it, the Cloudflare Turnstile check run inside the sign-in system itself, so they cannot be skipped by calling the backend directly. The optional AUTH_PROXY_SECRET setting goes one step further: with it, the backend refuses anyone who calls it directly to get around your sign-in protection, and the sign-in rate limit counts per visitor IP instead of per email. It is optional but strongly recommended, and the order you set it in matters. See Environment and Configuration.
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.
Uploaded files - images and course video - are validated on the way in and stored in a storage service under your own account. Members can attach only files they uploaded themselves, and deleting something removes only the files that belong to it. Live video runs through a third-party real-time provider (Daily.co) connected with your own credentials, and since v2.2.0 recordings stay in that Daily.co account. The "Watch recording" links show only to active members, but a recording link itself works for anyone who has it, so treat a copied link like a shared file. To remove a recording completely, delete it in Daily.co.
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.
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 - applying any critical fixes that ship, maintaining changes you make yourself, 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.