Security

1. Overview

• All traffic to Telbase (website, dashboard, API, CLI) is served over HTTPS.
• Environment variables and database connection strings are encrypted with AES-256-GCM before they are stored.
• Sign-in with Google, GitHub, or email and password. Passwords are stored only as scrypt hashes.
• The CLI signs in through a device flow that requires you to confirm a code and click Authorize in the browser while signed in.
• Organizations have owner, admin, member and viewer roles.
• Applications and databases run on Vercel, Google Cloud, Neon and Turso, in those providers' isolated environments.

2. What We Do Not Have Yet

We would rather you plan around these than discover them later.

• Instant access-token revocation. Signing out revokes your session on the server, so the refresh token stops working at once; an already-issued access token stays valid until it expires, at most 12 hours later.
• Managed database backups. Telbase does not create, list or restore database backups on any plan. Export your own data (see Databases).
• Blocking dependency checks and static analysis in CI. Our CI runs type checks, lint, unit tests and a dependency audit report. The audit does not yet block a merge, and we run no static-analysis (SAST) scanning.
• Telbase-specific certifications. We hold no SOC 2, ISO 27001, HIPAA or PCI attestation of our own. See Compliance.
• Microsoft sign-in. It appears in some materials but is not enabled.

3. Infrastructure

3.1 Where things run

• Control plane and metadata database: Render (single region).
• Web frameworks (Next.js, Vite, Astro, static, Node): Vercel.
• Containers, Python, Go and other runtimes: Google Cloud Run, built with Google Cloud Build.
• PostgreSQL: Neon. SQLite: Turso. Cloud SQL: explicit opt-in only.
• DNS, CDN and custom domains: Cloudflare.

Each provider encrypts data at rest and in transit on its own infrastructure and holds its own certifications (listed in Compliance).

3.2 Network

• All connections to the control plane and to provider APIs use TLS.
• Database connections issued to your applications use TLS.
• The control plane's hosting origin is reachable directly as well as through Cloudflare; restricting ingress to Cloudflare is planned.

4. Your Data and Secrets

4.1 Environment variables and connection strings

• Encrypted with AES-256-GCM before being written to our database.
• Decrypted only to sync them to your application's provider, or when a user with the env.values.read permission asks to reveal them. Listings show masked values by default.
• NEXT_PUBLIC_* and similar build-time public variables are, by design, compiled into your client bundle.

4.2 Your source code

• Deploying from the CLI uploads an archive of your project. The control plane checks the archive's declared size and entry count against fixed limits, extracts it in a temporary directory, removes symbolic links and other non-regular entries, reads only regular files under the declared root directory, and hands the files to Vercel or uploads the archive to Google Cloud Build. Temporary directories are removed after the deploy and swept if a deploy is interrupted.
• Deploying from GitHub uses the Telbase GitHub App to read the repositories you have granted it. Telbase never pushes to your repositories.
• To diagnose failed deploys we keep a small diagnostic snapshot alongside the deploy record: well-known configuration and entry files (for example package.json, vercel.json, Dockerfile, src/index.ts), capped at 10 KB each, with .env files excluded except .env.example. Values that look like secrets are redacted before the snapshot is stored. Parts of it may be sent to Anthropic's API to generate a diagnosis; Anthropic is listed as a subprocessor in our Privacy Policy.

4.3 Deletion

Deleting a project deletes its provider resources, environment variables, deploy records and database. See the Privacy Policy for retention details.

5. Authentication

5.1 Signing in

• Google and GitHub via OAuth 2.0. Sign-in is refused unless the provider reports the email address as verified.
• Email and password. Passwords are hashed with scrypt; we never store the password itself. The email address must be verified before password sign-in works.

5.2 Sessions

• Sessions are JSON Web Tokens: an access token valid for 12 hours and a refresh token valid for 30 days. Every live refresh token has a server-side record.
• Refresh tokens are rotated on every use. If a rotated token is presented again, the whole session is revoked, because one of the two copies was not yours.
• Signing out revokes the session on the server; the refresh token stops working immediately and the access token expires within 12 hours (see section 2). Resetting your password revokes every session on your account.

5.3 CLI

• telbase auth login shows a one-time code in your terminal and opens the dashboard.
• You must be signed in, see the same code on the page, and click Authorize. You can also click Deny. Opening the link or signing in does not, by itself, connect a terminal.
• Requests expire after 15 minutes, are single-use, and polling is rate-limited.

5.4 Abuse controls

• Sign-in and registration attempts are rate-limited per source address; password-reset and verification emails are rate-limited per email address.
• Token and signature comparisons are constant-time.

5.5 Access to your deployed applications

Optionally, a deploy can restrict who may open the application by email address or email domain (--auth-emails, --auth-domains). This is enforced in front of your application through Cloudflare Access, which also manages those visitors' sessions.

6. Access Control

6.1 Roles

Role checks are enforced on project, deploy, environment, database, domain, team, storage, billing, GitHub, Slack and scheduled-job endpoints. Viewers cannot change anything.

6.2 Tenant isolation

Every project, service, environment variable, database and GitHub installation is bound to one organization, and every API request is resolved within the caller's organization before any provider is contacted.

6.3 GitHub

• The Telbase GitHub App reads the contents of the repositories you grant it and receives push events for them.
• Installations are linked to your organization only through the Connect flow in the dashboard.
• Telbase never writes to your repositories.

7. Application and Build Security

7.1 How we develop

• Every push and pull request runs type checking, linting and the unit test suites in GitHub Actions.
• We keep an independent security audit of the platform and track its findings to closure.
• Every push also produces a dependency audit report (npm audit) in CI. It does not yet block a merge, and we do not run static-analysis (SAST) scanning.

7.2 Builds

• Builds run on Vercel or Google Cloud Build, in the provider's isolated, ephemeral build environment.
• Before that, the control plane handles your archive as described in section 4.2.
• Environment variables are available during the build when needed (for example for database migrations).

7.3 Runtime

• Applications run in the provider's isolated runtime (Vercel functions and edge, or Cloud Run containers) with the provider's resource limits.
• After each deploy Telbase performs an HTTP health check against your application and reports the result.

8. Monitoring and Logging

• Control-plane errors are reported to Sentry.
• An audit log records sign-ins, deploys, environment variable changes, database operations, team and billing changes, and administrative actions. Secret values are never written to it.
• Application logs are those of the hosting provider and are shown in the dashboard and CLI.
• We do not yet publish a status page or log-retention commitments.

9. Incident Response

We are a small team and do not yet publish response-time targets. What we commit to:

• If we confirm a security incident affecting your data, we will email affected customers within 72 hours of confirmation with what was affected and what you should do.
• We will contain the incident, fix the cause, and publish a post-mortem to affected customers.

10. Vulnerability Disclosure

10.1 Reporting security issues

We appreciate responsible disclosure. If you find a security issue, email [email protected] with a description, steps to reproduce, the impact you believe it has, and how to reach you.

10.2 Our commitment

• We will acknowledge your report within two business days.
• We will keep you informed while we investigate and fix.
• We will not take legal action against good-faith research.
• We will credit you if you wish.

10.3 Scope

In scope: telbase.ai and *.telbase.ai, the Telbase CLI, and Telbase APIs.

Out of scope: customer applications deployed on Telbase (report to their owners), social engineering, denial of service, and physical attacks.

11. Compliance

11.1 Provider certifications

Our infrastructure providers hold, on their own infrastructure:

• Vercel: SOC 2 Type II, ISO 27001
• Google Cloud Platform: SOC 2 Type II, ISO 27001, HIPAA eligible, FedRAMP
• Render: SOC 2 Type II
• Neon: SOC 2 Type II
• Cloudflare: SOC 2, ISO 27001, PCI DSS

11.2 Telbase itself

Telbase does not hold SOC 2, ISO 27001, HIPAA or PCI DSS certification. A provider's certification does not extend to Telbase's own control plane.

11.3 Data protection

We process personal data in accordance with the GDPR and the CCPA as described in our Privacy Policy.

12. Contact