Every Vybe application is protected by default — behind authentication, encrypted in transit and at rest, and isolated from other workspaces. Security is built into every layer of the platform, not bolted on after the fact.
This page gives you a high-level view of the security architecture. For detailed coverage of specific topics, see the linked pages.
Infrastructure security
Vybe uses a layered infrastructure model. Each layer is purpose-built with its own security controls.
Internal databases
Every organization receives an isolated Neon PostgreSQL project, ensuring complete data separation between workspaces. Internal databases include:
- Encryption at rest — Neon handles base encryption for all stored data
- 7-day backup retention — Automatic backups with point-in-time restore to millisecond precision (retention is customizable)
- Project isolation — One organization’s data cannot be accessed from another organization’s project
Preview environment (sandbox)
During development, your app runs in a secure sandbox hosted on isolated infrastructure:
- Token-based authentication protects access to the sandbox
- Each app runs in its own container — one app cannot access another app’s code, data, or environment variables
- An error or crash in one sandbox does not affect other apps
- Each app has its own dedicated resources during development
Deployed applications
Published apps are deployed on Vercel/AWS infrastructure with:
- Global CDN for fast, reliable delivery
- Enterprise-grade hosting with automatic scaling
- All traffic served over HTTPS with no option to disable it
External database connections
When you connect external databases (PostgreSQL, MySQL, Redshift), Vybe applies additional protections:
- SSH tunneling — Connect securely to databases behind firewalls or private networks
- Parameterized queries — All queries use parameterized statements to prevent SQL injection
- Security middleware — Every query is routed through Vybe’s security layer for validation
- Read-only enforcement — Optional read-only mode prevents accidental writes to production databases
Security middleware
All requests to Vybe applications pass through a dedicated security middleware layer. This middleware:
- Authenticates every request — Verifies the user’s session and access level before the request reaches your app code
- Enforces access controls — Checks organization membership, app-level permissions, and path-level restrictions
- Is never AI-generated — The security middleware is hand-written infrastructure code, never created or modified by the AI coding agent
- Validates all API calls — Every API endpoint includes access control verification, enforced through CI checks
Vybe’s security middleware is part of the platform infrastructure, separate from your app code. The AI agent cannot modify or bypass it. This ensures consistent security enforcement regardless of what your app does.
Data encryption
At rest
All sensitive data is encrypted before storage:
| Data type | Encryption |
|---|
| Internal databases | Neon-managed encryption at rest |
| API keys, tokens, credentials | AES-256-GCM encryption before database storage |
| SSH private keys | AES-256-GCM encryption before database storage |
| OAuth tokens | AES-256-GCM encryption before database storage |
| Server secrets | AES-256-GCM encryption before database storage |
In transit
All traffic is encrypted using TLS/HTTPS:
- The Vybe dashboard and editor
- Deployed app URLs (
*.vybe.build)
- API calls between your app and Vybe services
- Integration connections to third-party services
- Secure cookie attributes enforced:
HttpOnly, Secure, SameSite
- Cross-subdomain communication protected with security headers
There is no option to disable HTTPS. All connections are encrypted by default.
Authentication and access control
User authentication
- OAuth via Google — Primary authentication method
- SSO — Planned for Enterprise plans
- Secure session management — Encrypted HTTP-only cookies with cross-subdomain support
- Session invalidation — Logout immediately invalidates the session server-side
Access control layers
Vybe enforces permissions at three levels:
| Level | What it controls | Example |
|---|
| Organization | What a member can do in the workspace | Editors can create apps; Members cannot |
| App | Who can access a specific app | Restricted apps visible only to granted users |
| Path | Who can access specific routes within an app | /admin page restricted to team leads |
No public exposure
Deployed apps are only accessible to authenticated members of your organization. There are no public URLs, no guest access, and no way to share an app with someone outside your org without adding them as a member.
Every request to a deployed app goes through the security middleware. If the user is not authenticated or does not have access, the request is rejected before it reaches your app code.
Integration security
OAuth tokens and API credentials for third-party services are managed securely through Vybe’s integration platform:
- OAuth connections to 3,000+ services (Slack, Salesforce, HubSpot, Jira, and more)
- Credentials managed through a secure provider — Auth tokens are stored encrypted and never exposed client-side
- Automatic token refresh — OAuth tokens are refreshed automatically before they expire
- No direct credential access — Your app accesses integration data through Vybe’s APIs, which handle authentication on your behalf
API authentication
Vybe uses two credentials together to authenticate API calls from deployed apps:
| Credential | Identifies | Purpose |
|---|
VYBE_SERVER_SECRET | The app | Authenticates server-to-server requests |
x-vybe-user-token (VUT) | The user | Short-lived JWT identifying the current user |
Audit trail
Vybe tracks changes to your apps through version history. Every modification — whether by the AI agent or manually in the code editor — is recorded with:
- Who made the change
- When the change was made
- What was changed (full code diffs)
You can review the version history from the app editor and roll back to any previous version.
Compliance and certifications
| Standard | Status |
|---|
| SOC 2 Type II | Certified — independently audited |
| Penetration testing | Regular third-party assessments |
| OWASP guidelines | Adhered to across the platform |
| Dependency reviews | Automated security scanning of dependencies |
| Secure coding practices | Enforced through CI and code review |
Vulnerability reporting
If you discover a security vulnerability, report it to [email protected]. Vybe follows a responsible disclosure process:
- Reports are acknowledged and triaged promptly
- Dedicated incident response and monitoring
- Transparent communication with affected customers
- Fixes are prioritized based on severity
Security summary
| Layer | Protection |
|---|
| Infrastructure | Isolated Neon projects, sandboxed development, Vercel/AWS hosting |
| Data at rest | AES-256-GCM encryption for all secrets; Neon encryption for databases |
| Data in transit | TLS/HTTPS for all connections; secure cookie attributes |
| Authentication | OAuth, encrypted HTTP-only cookies, cross-subdomain sessions |
| Authorization | Role-based access at org, app, and path levels; CI-enforced checks |
| Middleware | Hand-written security layer; never AI-generated or AI-modifiable |
| Integrations | Encrypted credential storage; automatic token refresh; no client-side exposure |
| API authentication | Two-factor: server secret (app identity) + user token (user identity) |
| Compliance | SOC 2 Type II certified; regular penetration testing |
| Audit | Version history with author, timestamp, and code diffs |
| Exposure | No public URLs — all access requires authentication |
What’s next
