menu
save_alt 다운로드

Business Continuity Plan

Business operations continuity during service disruptions

< Back

Purpose

This plan defines how Beekeeper Studio maintains business operations during service disruptions. It complements the Disaster Recovery Plan, which covers technical restore procedures. This document focuses on keeping the business running: communication, decision-making, role succession, and operational continuity.

Key distinction:

  • Disaster Recovery = restore services (technical procedures)
  • Business Continuity = keep the business running (operations, communication, decisions)

Our advantage: Beekeeper Studio is a desktop application. Customers can use the app to connect to and manage their databases without any dependency on our cloud services. Cloud disruptions affect account management, billing, licensing, and optional features, but never block customers from doing their core work.

1. Critical Services & Impact Analysis

Services ranked by business criticality, with acceptable downtime targets.

1.1 Tier 1: Core Product (Desktop Application)

Component RTO RPO Impact if Unavailable
Desktop app (installed) N/A N/A Already on customer devices, works independently
Auto-update distribution 48 hours N/A Customers use current version; manual download available
Code signing certificates 72 hours N/A Delays new releases only

The desktop app has no dependency on our cloud services. Customers experience zero disruption to database connectivity, query execution, or local features during any cloud outage.

1.2 Tier 2: Revenue & Access

Component RTO RPO Impact if Unavailable
License validation 4 hours 1 hour New activations blocked; existing licenses have grace period
Billing (Stripe) 4 hours 1 hour Cannot process new subscriptions or changes
Cloud app (Heroku) 4 hours 1 hour Account management unavailable

1.3 Tier 3: Support & Communication

Component RTO RPO Impact if Unavailable
Email / support system 8 hours 4 hours Customer support delayed
Marketing site (Netlify) 24 hours N/A Downloads and docs unavailable
Status page 2 hours N/A Cannot communicate outage status

1.4 Tier 4: Internal Operations

Component RTO RPO Impact if Unavailable
GitHub (code repository) 24 hours 24 hours Development paused
Papertrail (logs) 24 hours 24 hours Reduced observability
Honeybadger (errors) 24 hours 24 hours Error tracking paused

2. Disruption Scenarios

2.1 Heroku Platform Outage

Impact: Cloud app, license validation, and billing unavailable.
Customer impact: Existing desktop app users unaffected. New activations and account changes blocked.

Response:

  1. Monitor Heroku Status for updates
  2. Post status update to customers (see Communication Plan)
  3. If outage exceeds 4 hours, evaluate temporary migration to alternative PaaS
  4. Heroku manages all infrastructure recovery; our role is communication and patience

2.2 Database Loss

Impact: Customer account data, subscription records, workspace sync data.

Response:

  1. Follow Disaster Recovery Plan restore procedures
  2. Restore from most recent Heroku Postgres backup or AWS S3 offsite backup
  3. Communicate expected downtime to customers
  4. Desktop app continues working throughout

2.3 Key Personnel Unavailable

Impact: Decision-making, incident response, deployments.

Response: Follow Role Succession plan (Section 4).

2.4 Critical Vendor Discontinuation

Impact: Varies by vendor. See Vendor Continuity (Section 5) for migration paths.

Response:

  1. Assess timeline for vendor shutdown
  2. Begin migration to alternative per vendor continuity plan
  3. Communicate any service changes to customers

2.5 Security Incident

Impact: Potential data exposure, service shutdown for containment.

Response: Follow Incident Response Plan. This BCP applies to maintaining business operations during and after the incident response.

3. Communication Plan

3.1 Internal Communication

Escalation chain (use first available):

  1. Slack - Primary channel, immediate
  2. Email - If Slack unavailable
  3. Phone/SMS - If email unavailable or urgent

Internal status update template:

SERVICE DISRUPTION - [Service Name]

Time detected: [timestamp]
Impact: [what's affected]
Customer impact: [what customers experience]
Status: [Investigating / Mitigating / Resolved]
ETA: [estimated resolution or "unknown"]

Next update: [time]

3.2 External Communication

Channels (in order of priority):

  1. Status page - First update within 30 minutes of confirmed disruption
  2. Twitter/X - Brief update with link to status page
  3. Email - For extended outages (>2 hours) or data-affecting incidents

Customer notification template (service disruption):

Beekeeper Studio Service Update

We’re currently experiencing a disruption to [service name]. [Brief description of impact].

What’s affected: [specific features/services]
What’s NOT affected: The Beekeeper Studio desktop app continues to work normally. All database connections and local features are unaffected.

We’re actively working on resolution and will provide updates [via status page / every X hours].

Thank you for your patience.

Customer notification template (resolution):

Beekeeper Studio Service Restored

The disruption to [service name] has been resolved as of [time]. All services are operating normally.

What happened: [brief explanation]
Duration: [start time] to [end time]

We apologize for the inconvenience. If you experience any remaining issues, contact support@beekeeperstudio.io.

3.3 Communication Timing

Outage Duration Action
0-15 minutes Investigate, no external communication
15-60 minutes Post to status page
1-4 hours Status page + Twitter + in-app notice if possible
4+ hours All channels + email to affected customers
24+ hours Daily email updates until resolved

4. Role Succession

4.1 Primary Roles

Role Primary Successor
Incident Commander Founder/CTO Senior Engineer
Technical Response Founder/CTO Senior Engineer
Customer Communication Founder/CTO Support Lead
Billing / Finance Founder/CTO COO or designated team member

4.2 If Founder/CTO is Unavailable

Short-term (< 1 week):

  • Senior engineer handles technical decisions and deploys
  • Support lead handles customer communication
  • No changes to billing or contracts

Long-term (> 1 week):

  • Designated successor assumes operational decision-making
  • Legal counsel engaged for any contract or compliance decisions
  • Board/advisors notified

4.3 Critical Access

All production credentials and access tokens are stored in Bitwarden. Emergency access procedure:

  1. Successor authenticates with their own Bitwarden account
  2. Uses shared vault for production credentials
  3. Bitwarden Emergency Access feature grants vault access if primary owner is unresponsive for configured waiting period

Ensure these are always current:

  • Heroku account access
  • AWS credentials
  • GitHub organization admin
  • Stripe dashboard access
  • Domain registrar access
  • Code signing certificate access

5. Vendor Continuity

5.1 Hosting & Infrastructure

Vendor Service Alternative Migration Effort
Heroku App hosting Railway, Render, or AWS ECS 1-2 weeks
Heroku Postgres Database AWS RDS, Railway Postgres 1-3 days (pg_dump/restore)
AWS S3 Offsite backups GCS, Backblaze B2 1-2 days

5.2 Services

Vendor Service Alternative Migration Effort
Netlify Marketing site Cloudflare Pages, Vercel 1-2 days
GitHub Code repository GitLab, Bitbucket 1 week
Stripe Billing Paddle, Lemon Squeezy 2-4 weeks
Papertrail Logging Datadog, Logtail 1-2 days
Honeybadger Error tracking Sentry, Bugsnag 1-2 days

5.3 Migration Triggers

Begin evaluating migration when:

  • Vendor announces end-of-life or significant pricing changes
  • Vendor experiences repeated outages (3+ in 30 days)
  • Vendor is acquired and roadmap becomes uncertain
  • Security incident originating from vendor

6. Desktop App Continuity

The desktop application is the core product and operates independently of cloud services.

6.1 What Works Without Cloud Services

  • All database connections (direct from customer device to their database)
  • Query execution, table management, and all local features
  • Saved connections and queries stored locally
  • Import/export functionality

6.2 What Requires Cloud Services

  • New license activations and subscription changes
  • Cloud workspace sync (optional feature)
  • Account management and billing
  • Auto-update checks

6.3 License Grace Period

The desktop app includes a license grace period. If license validation is unreachable, paid features continue to work for a configured grace period. This ensures customers are not disrupted by temporary cloud outages.

6.4 Distribution Continuity

Channel Primary Backup
Auto-update Built-in updater Manual download from website
Website downloads beekeeperstudio.io (Netlify) GitHub Releases page
Package managers Snap, Homebrew, Chocolatey, etc. Direct download
Code signing Current certificates Certificate renewal via signing authority

If the marketing site is down, customers can always download from GitHub Releases.

7. Recovery Priorities

When multiple services are disrupted, restore in this order:

  1. License validation - Unblock new activations and renewals
  2. Cloud application - Restore account management and workspace sync
  3. Database - Restore from backup if needed (see Disaster Recovery Plan)
  4. Billing (Stripe integration) - Restore subscription processing
  5. Status page - Restore communication channel
  6. Marketing site - Restore downloads and documentation
  7. Support systems - Restore customer support
  8. Monitoring and logging - Restore observability

8. Physical Security & Natural Disasters

8.1 Physical Security Posture

Beekeeper Studio is a fully remote company with no corporate offices, datacenters, or on-premise servers. All infrastructure runs on managed platforms (Heroku, AWS S3, Netlify). This means:

  • No physical datacenter risk — Heroku and AWS manage physical security, environmental controls, and redundancy for our infrastructure
  • No office security concerns — No server rooms, network closets, or physical access controls to manage
  • No on-site equipment — No corporate network, no on-premise backup systems

8.2 Employee Device Security

Since all work happens on personal or company-issued devices at employees’ homes:

  • Full-disk encryption required on all work devices (see Acceptable Use Policy)
  • Devices must be kept in a secure location when not in use
  • Lost or stolen devices reported immediately to CTO
  • Remote wipe capability maintained where possible

8.3 Natural Disaster Impact

If a team member’s location is affected by a natural disaster:

  • Team member communicates status when safe to do so
  • Work responsibilities shift to other team members per role succession (Section 4)
  • No customer data is at risk — all data is in cloud infrastructure, not on local devices
  • Business operations continue with remaining available team members

If a cloud provider’s region is affected:

  • Heroku and AWS maintain multi-region redundancy and their own disaster recovery
  • Follow vendor continuity procedures (Section 5) if recovery is prolonged
  • Our offsite backups in AWS S3 provide data recovery independent of Heroku

8.4 Summary for Security Questionnaires

Beekeeper Studio is fully remote with no corporate offices or on-premise infrastructure. All production systems run on managed platforms (Heroku, AWS) with provider-managed physical security, environmental controls, and disaster recovery. Employee devices are secured with full-disk encryption, and no customer data is stored on employee devices. Natural disasters affecting individual team members do not impact service availability.

9. Testing

8.1 Annual Tabletop Exercise

Conduct a tabletop exercise during the November compliance review week:

  1. Select a disruption scenario from Section 2
  2. Walk through the response procedures as a team
  3. Verify contact information and access credentials are current
  4. Identify gaps or outdated procedures
  5. Update this plan with findings

8.2 Ongoing Verification

Activity Frequency
Verify emergency contact information Quarterly
Test backup restoration Monthly (per Disaster Recovery Plan)
Review vendor alternatives Annually
Verify Bitwarden emergency access Annually
Update role succession assignments When team changes

Document Information

Version: 1.0
Effective Date: 2026-03-09
Last Reviewed: 2026-03-09
Next Review Due: 2027-03-09
Owner: CTO / Security Contact
Approved By: CEO

Security & Operations Policies