Security

Rackvio holds a map of your physical infrastructure — where equipment sits, what it draws, and which customer owns it. That is sensitive whether or not it contains personal data, so this page describes what we actually do rather than what sounds reassuring.

Two sections matter most to a reviewer: what you can verify yourself without taking our word for anything, and what we do not have yet. Both are below. Rackvio is operated by CalRen Solutions LLC.

1. What you can verify today

These are artifacts, not assertions. Each can be checked independently, without contacting us.

• Signed release artifacts. Every released container image is signed with cosign using keyless signing tied to the GitHub Actions workflow that built it. You can verify the signature against our workflow identity before running anything.
• Software Bill of Materials. A CycloneDX SBOM is generated and attested for every release, so you can audit our dependency tree against your own vulnerability feed rather than waiting for us to tell you about a CVE. SBOM documentation.
• Network traffic policy. The self-hosted Community Edition makes no outbound calls: no phone-home, no license checks, no telemetry. The policy documents the full internal traffic matrix so you can confirm it with your own egress monitoring. Traffic policy.
• Published API surface. The complete OpenAPI specification is published, so every endpoint, parameter and response shape is reviewable up front.
• Air-gapped deployment. Community Edition runs fully disconnected, including the equipment library via a signed offline bundle. The strongest verification is running it on an isolated network and watching it need nothing.

2. Product security controls

• Authentication. Passwords are hashed with bcrypt and never stored or logged in plaintext. Cloud plans from Starter upward can additionally delegate authentication entirely to SSO via Google, Azure AD and Okta, with OIDC tokens validated against the provider's published signing keys — in which case your identity provider owns the second factor instead of us.
• Multi-factor authentication, in every edition. Password logins support a TOTP second factor (RFC 6238) from any standard authenticator app. TOTP secrets are encrypted at rest; recovery codes are single-use and hashed with bcrypt; an administrator can reset another user's enrolment and that reset is recorded in the audit log with actor, target and timestamp. Organizations can require MFA account-wide, with a grace period that prompts rather than locks people out. This is available on every plan, including the free self-hosted Community Edition — a second factor is a security baseline, not an upsell. We do not offer SMS or emailed one-time codes, deliberately: NIST SP 800-63B discourages SMS, and an emailed code is not a second factor when password reset targets the same mailbox. WebAuthn and passkeys are not supported yet.
• Role-based access control. Four roles — administrator, operator, read-only and a restricted service role — gate every write. Administrative surfaces such as user management and audit history are administrator-only.
• Tenant isolation. Separation between organizations, and between colocation customers within an organization, is enforced in the database itself through row-level security rather than only in application code, so a missed check in a query cannot expose another tenant's rows.
• Audit logging. Administrative and data-changing actions are recorded with the acting user and timestamp. Query and export are available on Enterprise.
• Editions are separated at build time. Paid functionality is not merely hidden in the Community build — it is removed from the image, so those endpoints do not exist rather than being disabled by a flag someone could flip.

3. Hosting, data and continuity

• Hosting. The Cloud service runs on Amazon Web Services in the United States (us-east-1). Self-hosted deployments run entirely on your own infrastructure, in a location of your choosing.
• In transit. All traffic is served over TLS with certificates renewed automatically. Plain HTTP is redirected, not served.
• At rest. Cloud data sits on Amazon Lightsail block storage, which AWS encrypts at rest by default, as are the snapshots taken from it. The keys are managed by AWS rather than by us — we do not currently offer customer-managed keys, and if your review requires them, say so early.
• Backups. Two independent layers. The instance is snapshotted daily by AWS, with the seven most recent retained and stored outside the instance itself. Separately, the database is dumped daily on the instance and kept for 14 days, which is what makes a single-database restore possible without rebuilding a whole machine. Restores are exercised by restoring a real dump into a scratch database and checking the row counts, not assumed to work.
• Data export. Every plan includes full export of your data at any time, so leaving does not require our cooperation. Enterprise customers may request a source escrow agreement.
• Sub-processors. Handling your Rackvio data: Amazon Web Services (hosting and transactional email via SES), Stripe (payment processing — card details go from your browser to Stripe and never reach our servers), and Anthropic (only for the optional in-app AI assistant, on Cloud Growth and above). The assistant does not log the content of your questions. Not touching your infrastructure data: Hostinger hosts this marketing site and the documentation site, and its server receives what you submit through forms here — including signup — before forwarding it to the application on AWS. Cloudflare provides the bot-protection challenge on the signup form, and HubSpot holds sales and marketing contact records. None of the three has access to the application or its database. Sentry is integrated for error monitoring but is switched off and receives nothing; we will say so here before enabling it. See our Privacy Policy and Data Processing Addendum.

4. What we do not have yet

We would rather you learn this here than discover it in week three of a procurement review.

• No SOC 2 report, and no third-party penetration test. Both are on our roadmap. We do not publish a target date for either until it is committed, because a date that slips is worth less to your security team than no date at all.
• No WebAuthn or passkeys, and no hardware-key support. TOTP is available on every plan (see section 2), but phishing- resistant factors are not yet. It is the next authentication item we are building.
• Backups are not in a second region. Daily instance snapshots and daily database dumps both run and are retained, but both live in the same AWS region as the service, so a region-wide event is not covered by either.
• We are a small team. That has real consequences for separation of duties, and we would rather state it than let a questionnaire imply a security organization that does not exist.

5. Reporting a vulnerability

Email contact@rackvio.com with "Security" in the subject line. Please include enough detail to reproduce the issue. We will acknowledge your report, keep you updated as we work on it, and credit you if you would like to be credited.

We ask that you give us a reasonable opportunity to fix an issue before disclosing it publicly, and that you avoid accessing or modifying other people's data while testing. We will not pursue legal action against researchers acting in good faith under those terms.