Cloud Platforms
Our supported cloud platforms are DigitalOcean and Microsoft Azure. New systems should be deployed on one of these platforms unless there is a documented architectural reason to do otherwise.
Cloud platform selection should be intentional. The goal is not to chase platform features by default, but to choose the simplest platform that satisfies the system’s operational, security, integration, and scaling requirements.
Default Standard
Section titled “Default Standard”DigitalOcean is the default starting point for most standard web applications, APIs, internal tools, scheduled jobs, and small-to-medium service workloads.
Microsoft Azure should be chosen when a system has clear requirements that benefit from Azure’s enterprise capabilities, Microsoft ecosystem integrations, or organizational controls.
Selecting Azure instead of DigitalOcean should be a deliberate architectural decision, not a default assumption.
When to Use DigitalOcean
Section titled “When to Use DigitalOcean”Prefer DigitalOcean when a system needs:
- Straightforward hosting for a web application, API, background worker, or internal tool
- Managed infrastructure with low operational overhead
- Predictable deployment patterns for containers, virtual machines, databases, or object storage
- A simpler platform for teams that do not need deep enterprise cloud features
- Lower complexity for small or early-stage systems
DigitalOcean is usually the better fit when the workload is conventional and the team benefits more from simplicity and speed than from a broad catalog of platform services.
When to Use Azure
Section titled “When to Use Azure”Prefer Azure when a system needs:
- Integration with Microsoft-managed identity, access, or enterprise services
- Centralized secret management through services such as Azure Key Vault
- More advanced networking, policy, governance, or access-control requirements
- Organizational compliance or security requirements that are better served by Azure-native controls
- Platform services that are only available in Azure or are materially easier to operate there
Azure is typically the better fit for systems with stronger enterprise constraints, more complex infrastructure boundaries, or tighter alignment with existing Microsoft platforms.
Selection Criteria
Section titled “Selection Criteria”Before choosing a cloud platform, evaluate:
- Runtime needs such as containers, virtual machines, managed databases, object storage, queues, or scheduled jobs
- Security requirements including secret storage, network isolation, identity integration, and access review
- Operational complexity such as deployment workflows, monitoring, backups, and incident response
- Team familiarity with the platform and the expected support burden
- Cost predictability at the expected scale
- Whether the platform choice reduces or increases architectural complexity over the life of the system
If both platforms can satisfy the workload, choose the simpler option.
Baseline Expectations
Section titled “Baseline Expectations”Regardless of provider, cloud-hosted systems should follow these standards:
- Prefer managed services over self-managed infrastructure when they materially reduce operational burden
- Store secrets in a managed secrets system or secure environment configuration, never in source control
- Use least-privilege access for service accounts, databases, and infrastructure administration
- Keep infrastructure configuration repeatable and version controlled where practical
- Enable monitoring, alerting, and centralized logging appropriate to the criticality of the system
- Ensure databases, object storage, and other stateful systems have backup and recovery plans
- Separate production and non-production environments clearly
- Document the owning team, deployment model, and operational dependencies in the repository or service documentation
Cloud infrastructure should support the application architecture, not become an independent source of complexity.
Design Guidance
Section titled “Design Guidance”Platform selection does not replace good system design. When deploying services to either platform:
- Keep application configuration externalized through environment variables or managed configuration
- Package services consistently, typically with Docker
- Default to managed PostgreSQL for transactional application data unless a different database is justified
- Avoid tight coupling to provider-specific services unless the dependency is intentional and valuable
- Be explicit about ingress, TLS termination, background processing, and data storage responsibilities
Using provider-specific capabilities is acceptable when they clearly improve the system, but those choices should be understood as architectural dependencies rather than incidental implementation details.
What to Avoid
Section titled “What to Avoid”Avoid these common mistakes:
- Choosing Azure for a simple workload that does not need its additional complexity
- Introducing a second cloud provider without a clear business, technical, or compliance reason
- Running self-managed infrastructure when an appropriate managed service exists
- Embedding provider-specific assumptions deep inside business logic
- Making platform decisions based only on familiarity without evaluating operational fit
The best platform choice is usually the one that meets requirements with the fewest moving parts.