Skip to content
Start building

Trust & security

Security for the people shipping

Ship faster, with the controls your team and your customers expect.

Contact salesReport an issue

Find it before your customers do

Every Vibely app is scanned as it’s built. See how Vibely scans your app

  • Scanned as you build

    Every publish kicks off a background scan of your application code and any exposed PII. A deep scan, which you start on demand, adds your RLS policies, database schema and dependencies — five scanners in all.

  • Ranked by severity

    Findings land in the project Security view ordered by how much they matter, each one naming the file and the rule it broke, so you can tell a real hole from a style note.

  • Fixed before you ship

    Safe dependency fixes can be applied for you, and a workspace can block publishing outright while a critical finding or exposed PII is outstanding.

Every vendor that touches your data is listed.

Cloud hosting, sandboxes, AI inference, payments, email and observability — named, with the country each one runs in.

See every subprocessor
Uptime commitment (/sla)
99.5%
In transit and at rest
Encrypted
Sandbox isolation
Per-project
Vibely trains models on your data
Never

The controls your security team expects

Enforce SSO and role-based access, keep publishing behind separate permissions, and know that Vibely itself never trains models on your code or prompts.

  • Access and control

    SAML or OIDC single sign-on with optional SCIM provisioning on Business workspaces. Owner, Admin, Editor and Viewer roles are evaluated server-side on every request — viewing, editing, publishing and publishing publicly are separate permissions.

  • Guardrails for building & publishing

    Editing, publishing and publishing publicly are separate permissions, and every project carries its own visibility — public, private, workspace, or named member groups. Teams move fast without exposing in-progress work.

  • Secrets handled securely

    Encrypted at rest, scoped to your workspace, and never returned in plaintext. Rotate or revoke one and every running sandbox picks up the change immediately — no redeploy.

  • Where your data runs

    Application servers and project sandboxes run in AWS us-east-1; the database, authentication and file storage run on Supabase in Singapore. Every subprocessor and its location is listed in Annex 3 of our DPA at /dpa. There is no region selector yet.
    See subprocessors

  • Vibely does not train on your data

    Vibely does not use your prompts, code, or project data to train models. The model that serves a request processes it under its provider's own terms: the default, DeepSeek, permits using inputs to improve its models and processes data in China; OpenAI, Anthropic, Google and Fireworks exclude API traffic from training. Product-improvement data collection is off by default; a workspace can opt in from Privacy & security settings.

  • Isolation by design

    Strict logical separation between workspaces and projects with row-level security on shared databases. Boundaries are explicit before publishing.

  • Continuous monitoring

    Rate limiting and abuse detection on the agent loop, applied at the IP, user and workspace level. Runtime errors and anomalies surface in our observability stack and we review what it flags.

  • Automatic security scanning

    Scanners check your RLS policies, database schema, application code, dependencies and exposed PII. Findings are ranked by severity in the project Security view before you publish.
    Security scans

  • Protected infrastructure

    Every build runs in its own cloud sandbox with its own filesystem, behind an edge CDN on every route. Vibely never enters your environment and needs no inbound connection from your network.

Built for the way you ship

Evidence you can hand over

Export your scan findings as a report for a customer security review or investor diligence. It is a scan result, not a SOC 2 or ISO 27001 audit — but it shows exactly what was checked and what you fixed.

Security answers for founders

Ask us what we can evidence today — how builds are isolated, which subprocessors touch your data, and what we hold and do not hold on the compliance side. We hold no SOC 2 report and no ISO 27001 certificate. We answer in writing.

Find vulnerabilities before they find you

Five scanners check your RLS policies, database schema, application code, dependencies and exposed PII on a deep scan you run on demand; every publish additionally kicks off a background code and PII scan. Business workspaces can schedule recurring deep scans, and the safe dependency fixes can be applied for you.

Frameworks we support

  • SOC 2Not held

    We do not hold a SOC 2 report and no audit is under way. We will say so here on the day we engage an auditor, rather than before.

  • GDPREU data protection

    Article 28 Data Processing Agreement published at /dpa, including the EU SCCs and the UK Addendum. It applies without signature.

  • ISO 27001Not held

    We do not hold an ISO 27001 certificate and no certification process is under way. What we run is described on this page; none of it is externally attested.

Found a vulnerability in Vibely itself? Read the responsible disclosure policy or the Data Processing Agreement.

FAQs

Application servers and project sandboxes run in the United States (AWS us-east-1). The primary database, authentication and file storage run on Supabase in Singapore (ap-southeast-1), and our team accesses both from India. We do not operate an EU or India hosting region today and we are not naming a date for one. Every subprocessor and its location is listed in Annex 3 of our DPA at /dpa.

Vibely does not use your prompts, code, or project data to train models. OpenAI, Anthropic, Google and Fireworks exclude API traffic from model training under their standard API terms. DeepSeek is used under its standard terms, which permit using inputs to improve its models, and processes data in China. Product-improvement data collection is off by default on every plan and carries usage metrics only — model, provider, token counts and cost — never prompts or code; the control is at Settings → Privacy & security → Data protection.

Vibely is multi-tenant with logical isolation between workspaces and projects: authorization is evaluated server-side on every request, shared database tables carry row-level security, and each project builds and runs in its own cloud sandbox with its own filesystem. It is logical isolation, not physical, and no third party has audited it.

A small, deliberate set of subprocessors (cloud hosting, sandboxes, AI inference, payments, email, observability, analytics, the connector OAuth gateway and the mobile build pipeline). Each is engaged under that vendor's own published data processing terms where it offers them; we do not hold a negotiated agreement with every vendor and we do not claim every vendor's terms match our DPA at /dpa. The current list is public in Annex 3 of our DPA, and the position vendor by vendor is available from [email protected].

Vibely generates and runs your project inside its own isolated sandbox — it does not enter your environments or require CI/CD access. If you connect a GitHub repository, Vibely reads and writes files in exactly the repositories you select, through the GitHub App you install, which can only reach the repositories you selected when you installed it. That access can be revoked from GitHub at any time. The scope of what we can see is the scope you granted GitHub.

No. Vibely does not deploy agents into your production environments and does not require any inbound connections from your network.

Publishing is enforced server-side with separate role-based permissions: Owners, Admins and Editors can publish, while only Owners and Admins can make a project publicly accessible. A workspace can also block publishing when a scan reports critical findings or exposed PII.

Roles are Owner, Admin, Editor and Viewer, and every request is authorized server-side against an explicit permission. Business workspaces can drive membership from a SAML or OIDC identity provider, with optional SCIM provisioning.

Yes. Viewing, editing, deleting, publishing and publishing publicly are separate permissions, and member groups let you scope a single project to part of the workspace — so every member only has the access they need.

Secrets are encrypted at rest, scoped to your workspace, and role-controlled — the API never returns a value in plaintext. Rotating or revoking one takes effect in running sandboxes immediately, without a redeploy.

Yes, on every plan. A basic scan of your application code and exposed sensitive data (PII) runs on every publish. A deep scan, which you run on demand, adds dependencies, row-level security policies and database checks, and Business workspaces can schedule recurring deep scans. Findings are ranked by severity, with suggested fixes.

GDPR: our Article 28 Data Processing Agreement is published at /dpa and applies without signature. SOC 2 and ISO 27001: we hold neither, and no audit or certification process against either is under way. We would rather say that than describe a programme we have not started. If one begins, this page says so on the day it does.

Vibely is a general-purpose AI development tool, not a high-risk AI system under the EU AI Act — the apps you build with it are your own products and your own compliance responsibility. Vibely follows GDPR data protection practices for the platform itself; see our Data Processing Agreement at /dpa.

Build with confidence

Each model provider processes your requests under its own terms. The default build model, DeepSeek (selected by Auto), permits using inputs to improve its models and processes data in China. Pick another model in the composer if that matters to you.

Contact salesData Processing Agreement