Self-Hosting
Self-hosting StudioBrain lets your studio run the platform on infrastructure you control. It is a good fit when you need stricter data residency, custom networking, or operational control over upgrades and integrations.
What self-hosting includes
A typical self-hosted deployment includes:
- A StudioBrain application server reachable over HTTPS
- A PostgreSQL database for app data
- Persistent storage for uploaded content and generated files
- A reverse proxy or load balancer in front of the app
- Optional AI or GPU services if you plan to run local model workloads
For many teams, a single application node plus a managed PostgreSQL instance is enough to get started. Larger teams usually separate the database, storage, and AI workloads so each layer can scale independently.
Before you begin
Plan these pieces before you deploy:
- Domain and TLS: Choose the public hostname your users will sign in to and terminate HTTPS there.
- Database: Provision PostgreSQL with regular backups and a tested restore process.
- Storage: Decide whether StudioBrain content stays on attached disk or an object storage provider.
- Secrets: Prepare a stable
JWT_SECRET, database credentials, storage credentials, and any AI provider keys you plan to use. - Operations ownership: Decide who will handle upgrades, incident response, monitoring, and user support.
Use a stable JWT_SECRET from day one. Rotating it unexpectedly logs out every active user and invalidates existing sessions.
Recommended rollout
1. Prepare infrastructure
Start with a reachable hostname, TLS certificates, database connectivity, and persistent storage. Make sure the StudioBrain app can reach every dependency before users are invited.
2. Configure the environment
Set the application URL, database connection string, JWT secret, storage settings, and any optional AI provider credentials. Keep secrets outside source control and rotate them through your normal secret-management process.
3. Start StudioBrain
Bring up the application stack and confirm that:
- the web app loads over HTTPS
- the backend can connect to PostgreSQL
- file uploads land in the expected storage location
- new logins succeed
4. Create the first admin account
After the service is reachable, create or promote the first administrator account for your studio. That admin can then invite the rest of the team and manage storage, sync, and account settings from inside the product.
5. Connect clients
Point your users at the instance URL:
- Web: users sign in directly through the browser
- Desktop: users enter the self-hosted instance URL in the cloud connection settings
- Mobile: users sign in to the same instance from iOS or Android
Day-2 operations
Self-hosting is not just initial deployment. Plan for the ongoing work as well:
- Backups: back up PostgreSQL and user content on a schedule you have already tested
- Upgrades: stage upgrades in a non-production environment before you roll them out to users
- Monitoring: watch application health, disk usage, database health, and certificate expiry
- Access control: review admin access, API keys, and service credentials regularly
- Capacity: revisit CPU, memory, storage, and database sizing as your content library grows
What stays public vs. internal
This guide covers public-facing deployment guidance only. Studio-specific hardening details such as private network topology, internal hostnames, VPN layout, or incident-response runbooks should stay in your private operations documentation.