Your brand on the outside. Your infrastructure on the inside.
Each community gets its own Postgres database and two containers, with password, session key, and push keys generated on the spot — not a reserved space inside someone else's server. The brand runs from the domain to the email sender.
This page goes down the brand layer in the order it's perceived: the address, the surface, the sender. Then it lists, with the file path, what's shared between customers. And it closes with what it refuses to promise.
One database for you. Not a reserved spot in someone else's database.
When payment confirms, provisioning runs nine steps.
Step 3 creates a Postgres database exclusive to your community, with a password generated on the spot: 24 random bytes that no one typed or saved in a document. Step 6 brings up your API container with your own DATABASE_URL, a JWT_SECRET of 32 bytes that's yours alone, and a VAPID key pair generated for your community at that instant — your members' push notifications are signed with a key that exists in no other customer. Step 7 brings up the site container, with your domain. Step 8 deploys both and tracks each one's status until it responds healthy: twelve checks of ten seconds each, with up to two automatic redeploys if one comes up broken.
The customer next door's database is a different process, a different volume, a different password. A heavy query from them runs on their own Postgres.
Provisioning is also resumable: steps already completed are skipped, and a single step can be re-run without redoing the ones before it.
The isolation here is at the infrastructure level, not the column level. What's separated is the deploy — database, containers, and secrets — not the data model.
The address is yours. And the certificate is verified before the link goes out.
A custom domain is set up right inside the dashboard, at /admin/domain, with no support ticket needed. The screen shows the two CNAMEs you need to create — your domain and api.yourdomain — and the target for each. You save, and provisioning swaps the domain on both containers, rewrites API_URL and NEXT_PUBLIC_API_URL on the site, CORS_ORIGINS and APP_URL on the API, and restarts both.
The first provisioning run has one extra step. Before marking your community as ready, the system makes a real GET request over https:// to the site's domain and the API's. A certificate not yet issued, or the default self-signed one, breaks the handshake — and it retries every five seconds, up to 36 times, per address.
In practice, this step exists so you don't end up with a URL that opens with an insecure-connection warning the first time a student clicks it.
It's a check, not a lock. Once the retries run out with no valid certificate, the code logs a warning and moves on instead of failing the entire provisioning run — it reduces the chance of the error, it doesn't guarantee it never happens.
From three colors to fifteen. You choose where to stop.
Simple mode: three colors and done. Advanced mode: fifteen named colors — primary, secondary, accent, success, warning, error, info, three for background, three for text, and two for borders — with a separate set for the dark theme. Plus typography: body font, heading font, and monospace, with 25 families for text, 8 for headings, and 9 monospace, along with base size, type scale, weights, and line height. Plus layout: border-radius scale and shadow scale.
Identity lives on the same screen: community name, tagline, logo, favicon, banner, and whether the logo shows with or without the name next to it.
The favicon and the OpenGraph image don't stop at the preview. The Next server queries the community's appearance and builds the tab icon, the title, the description, and the shared-link card. Whoever receives your course link on WhatsApp sees your image.
Each state becomes a named version you can restore later, and the entire theme exports and imports as JSON. The login and signup screen has its own customization: background, texture, side image, text, and card.
Login screen customization stops at two layouts, centered and split. There's no third one in the dashboard.
The email goes out with your name. The domain, once you turn on your own SMTP.
This is worth being exact about, because it's the point where almost every platform overpromises.
By default, transactional email works from the first minute, with nothing for you to configure. It goes out through the platform, with your community's name as the sender and the address on the mail.mentorflix.io domain using your slug, with reply-to set to the community owner's email. The name the student reads is yours. The domain, at this stage, isn't.
When you fill in host, port, credentials, and the "From" field and turn on your own sending in settings, the cascade changes: sending runs entirely through your own SMTP server, with the sender you wrote.
Eleven email types are editable by you: invite, welcome, password reset, weekly digest, badge earned, RSVP and event reminder, notification summary, announcement, challenge start, and mention. Each comes with documented available variables, keeps versions, restores a previous version, reverts to the default, and fires a test before you publish.
The "From" field matters. Left blank, sending falls back to a generic platform sender instead of your domain.
What's shared between customers. With the file path.
The first section of this page listed what runs just for you. This one lists the rest, because a list without the second half isn't worth anything.
Media is shared. Images and video go to a storage zone and a platform video library on Bunny, the same ones for every customer, with files separated into a folder by your slug, at comunidades/seu-slug/.
Default email sending uses a platform Resend account until you turn on your own SMTP, as the previous section described.
And the marketplace between members settles through the platform's Stripe account, via Connect.
If anyone claims everything is dedicated, ask for the file path.
These three points are exactly where the isolation from the first section stops. What's yours in the media is the folder path, not the zone.
What this page won't promise you.
Four claims common in the market that we can't back up with the code in hand, so we don't make them.
The first is backup. There's no backup routine in the repository. If one exists, it lives in the server configuration, outside of here — and we won't sell you a policy that isn't written anywhere you can audit.
The second is monitoring and alerting. There's also no observability or alerting code in the product.
The third is LGPD. There's no flow for consent, portability, or deletion at the data subject's request within the platform.
The fourth is export. What comes out today is analytics in CSV, lens by lens: growth, engagement, retention, content, and gamification. There's no export of members or of content. Promising there's no lock-in with that in hand would be a lie.
Four more small, real details: the HTTPS check runs during initial provisioning, not on a later domain change; the waits for container and certificate degrade into a log warning instead of failing; the appearance's components field exists in the database but has no editor in the dashboard; and your container's CPU and memory metrics exist as an endpoint on your own API, with no screen that shows them.
No uptime number appears on this page because none has been measured.
Continues in
A fixed price for dedicated infrastructure only adds up if no one takes a percentage of your sale. How the sale works: 01 · Sales →
The brand shows up in the invite, in the space, and in the member list. How each one is configured: 03 · Communities →