Back to homepage

Security

How Bstrapr approaches infrastructure access

Because Bstrapr sits between owners and collaborators on real infrastructure, trust requires precise claims. This page describes the access model — not marketing slogans.

Authentication and identity

Collaborators authenticate through Bstrapr before reaching Sites you have assigned. Access is tied to identity in your account, not to shared passwords left on machines.

Site enrollment and trust

You enroll infrastructure you already operate — cloud VMs, remote servers or designated machines. Enrollment establishes a Site under your ownership; Bstrapr does not take over your hosting provider.

Encryption and network path

Site connectivity uses encrypted VPN-style networking so collaborator traffic to enrolled Sites is carried over a protected path. Connectivity alone is not the product — authorization and lifecycle are.

Authorization and Site-scoped access

Grants are scoped to Sites. A contractor can be limited to one environment while your core team retains broader access. Broad environment credentials are not the default model.

How revocation is enforced

When you revoke a collaborator, Bstrapr-mediated access for that person ends. Your Site remains enrolled and under your control — you do not need to rebuild infrastructure to end an engagement.

Tenant isolation

Accounts, Sites and access relationships are isolated per customer context so one team’s collaborator model does not bleed into another’s.

What Bstrapr can and cannot see

Bstrapr manages access relationships and enrollment state. Application data, source code and workloads remain on your infrastructure. We do not claim visibility into your product content.

Credential and key handling

Prefer invite-and-grant workflows over sharing root passwords. Site enrollment and collaborator access are managed through the product so temporary workers are not left holding standing secrets.

Access activity history

You can review who was granted access, which Sites they could reach and when access changed. That history supports day-to-day accountability for lean teams and agencies.

We describe this as access activity history — not “audit-ready” compliance packaging — until immutable retention, evidence export and related controls are established for your deployment model.

Incident response and operations

Operational responsibility for the shared platform is ours; responsibility for your enrolled Sites and workloads remains yours. Dedicated deployments can define support and operational boundaries explicitly — see Dedicated or contact us.