VibeHost is operated by GNTC Inc. This page describes the security controls that apply to the VibeHost hosting platform — how uploads are validated, how access is gated, what is encrypted, and what is logged. It reflects how the service is actually built; it is not a forward-looking roadmap.
Certifications
VibeHost operates within GNTC Inc.’s ISO/IEC 27001 information security management system. The cloud infrastructure VibeHost runs on — Google Cloud for the control plane (API, dashboard, database, cache) and Cloudflare for edge delivery and object storage — is independently certified under the standards published by those providers (including ISO 27001 family, SOC, and PCI DSS). Certification documentation is available to enterprise customers on request.
Encryption
In transit
All connections between users and VibeHost, and to the API at api.vibehost.com, use TLS 1.2 or higher, terminated at the Cloudflare edge.
At rest
Deployment artifacts are stored as content-addressed blobs in Cloudflare R2, encrypted server-side with AES-256. Platform data lives in managed Google Cloud storage with encryption at rest.
Upload validation
Every deploy is a tarball upload, and unpacking is not trusted by default. The unpack path and the chunked blob-assembly path both reject absolute paths, .. traversal, disallowed symlinks, any entry over the per-file size ceiling, a total archive over the archive ceiling, and archives over the entry-count limit. Each guard is enforced in code and covered by a test — a tarball that violates any of them is rejected before anything is written to disk.
Build isolation
The default deploy path is client-side: the build runs on your machine and the server only accepts the finished artifact — no build tooling executes in the API hot path. When a server-side build is requested, it runs as a sandboxed Builder Job separated from the API. The tenant container runtime can additionally be configured to use gVisor (runsc) for kernel-level isolation; this is an available hardening option, not the default runtime.
Access controls
App access composes, it does not short-circuit. A viewer must satisfy every gate that is enabled: visibility (public / workspace / private) or an explicit per-app grant, AND the app password if one is set, AND a valid share-link cookie if a share link is in use. Grants are scoped per app (team or email, at viewer / deployer / admin level). Adding a new gate ANDs it in — gates never weaken each other.
Secrets and credentials
API tokens are never stored in plaintext: only a SHA-256 hash is persisted, and the plaintext is returned exactly once at issuance. Tokens are never written to logs. The CLI stores its token in a user-owned config file with restricted file permissions. Infrastructure secrets are kept out of the repository entirely.
Auditing and supply chain
Administrative actions are recorded to an audit log for incident analysis and accountability. Access logs (IP, request path, timestamp) are retained for 90 days for abuse prevention and billing. Dependencies are continuously scanned for known vulnerabilities and license issues in CI, and every change goes through code review before it can merge.
Reporting a vulnerability
If you believe you have found a security issue in VibeHost, please report it privately so we can investigate and fix it before any public disclosure. Do not include credentials, tokens, or third-party personal data in your report.
We aim to acknowledge a report within 5 business days and will keep you updated on remediation progress. We ask that you give us a reasonable window to ship a fix before disclosing publicly.