|
| 1 | +## ADR 008: Azure Virtual Machine (VM) for Deployment |
| 2 | + |
| 3 | +## Context |
| 4 | + |
| 5 | +We must deploy our application (Next.js app + Postiz Service Containers + database + media processing) to a publicly accessible environment. Our project does not offer reimbursement, so we require a solution that can be covered by free credits. Some cloud providers offer student credits which can fully cover a single small VM or container hosting in the short to mid term for a MVP. We would like a service with: |
| 6 | + |
| 7 | +- Predictable and controllable cost (ideally fixed monthly for chosen size) without opaque per-request/container consumption pricing that is more difficult to forecast. |
| 8 | +- A professional interface and enterprise-grade security/network features to practice realistic cloud operations. |
| 9 | +- Straightforward networking (static public IP, DNS, firewall) and ability to configure HTTPS termination (Nginx/Caddy) and reverse proxying for Next.js \+ API \+ Postiz stack processes. |
| 10 | +- Future expansion path: ability later to move to Containerized Apps, or App Service, etc. if needs scaling. |
| 11 | +- Some members of our team have familiarity with standard Linux server administration and have deployed applications on VMs previously. |
| 12 | + |
| 13 | +### Options |
| 14 | + |
| 15 | +1) Microsoft Azure Virtual Machines |
| 16 | +2) Microsoft Azure Container Apps / Container Instances (managed container/platform services) |
| 17 | +3) DigitalOcean Droplet (another VPS hosting service with student credits) |
| 18 | +4) Local hosting (on personal machines at home) |
| 19 | +5) Solutions from other major cloud providers (AWS, Google Cloud) |
| 20 | + |
| 21 | +## Decision |
| 22 | + |
| 23 | +We decided to use an Azure Linux Virtual Machine as the deployment target for the MVP. |
| 24 | + |
| 25 | +**Reason:** |
| 26 | +1) **Student Credits Coverage**: Azure’s student credit covers the VM cost eliminating out-of-pocket expense, vital due to reimbursement constraints. |
| 27 | +2) **Predictable Pricing**: Simple set per-hour (monthly) VM cost avoids surprises. This is important when we are limited to free credits and have not received any funding yet. In contrast, container-based per-resource/consumption pricing (CPU seconds, vCPU allocation, outbound data) is harder to forecast early. |
| 28 | +3) **Operational Flexibility**: Full OS access enables installing custom dependencies (image/video processing, build/automation tools), running multiple processes (web server, Postiz Stack, automation scripts) without separate services. |
| 29 | +4) **Mature Ecosystem & Skills Development**: Using a VM from a major cloud provider fosters practical experience with network security, system monitoring, configuration, and automation workflows. |
| 30 | +5) **Networking & SSL Simplicity**: Direct control of firewall (Network Security Groups) and reverse proxy (Nginx/Caddy) for TLS termination + compression + caching. |
| 31 | +6) **Upgrade Path**: Later containerization or migration to Azure Container Apps / App Service can reuse built artifacts. The current VM stage lets us stabilize our MVP first. |
| 32 | +7) **Single Surface for Logging/Observability**: Centralizing logs initially (journalctl, structured logs to file) reduces complexity vs multi-service logs. We can further integrate with Azure Monitor when ready. |
| 33 | +8) **Resource Sizing Control**: Ability to resize VM quickly if performance limits observed. We will have the option to create snapshots prior to changes reduce risk. |
| 34 | + |
| 35 | +## Status |
| 36 | + |
| 37 | +Accepted |
| 38 | + |
| 39 | +## Consequences |
| 40 | + |
| 41 | +By choosing Microsoft Azure Virtual Machines, we now have the benefit of: |
| 42 | + |
| 43 | +- Rapid and flexible machine environment setup, minimal abstraction between application and OS. |
| 44 | +- All components (Next.js server, Postiz docker containers, etc.) are co-located for low-latency internal communication. |
| 45 | +- Clear monthly cost tracking against student credits, no surprises. |
| 46 | + |
| 47 | +Also from this choice, we are now facing the following trade-offs: |
| 48 | + |
| 49 | +- We are now responsible to perform security hardening (disable password SSH and use keys, update packages, configure ports on firewall, etc.) |
| 50 | +- Need to monitor and manage OS updates and security patches manually. |
| 51 | +- Using a single VM is a single point of failure. This is mitigated by the multi-zone fallback configuration we use from Azure. We should also make snapshots and periodic backups (disk \+ DB) with incremental remote backup (e.g., Azure Blob) for critical data. |
| 52 | +- Horizontal scaling (multiple VMs, load balancers) requires additional setup not inherent to this decision. |
| 53 | +- Potential over-provisioning vs truly elastic container solutions. Requires manually choosing the correct VM size. |
| 54 | + |
| 55 | +## Potential Backups |
| 56 | + |
| 57 | +1) **DigitalOcean Droplet**: A similar VPS solution with student credits. Digital Ocean offers a simpler UI, and much more integrated packages (includes cost of disk, networking, IP on top of the VMs themselves) in terms of a VM, whereas in Azure we configure everything ourselves (attaching our own disks and setting up our own networking). |
| 58 | +2) **Azure Container Apps**: Managed scaling and deployment of containers. This option has a more unpredictable base cost for minimal usage, but can be better for the future when usage and cost of our application is better understood and we require more scaling than a single machine. |
| 59 | +3) **Local Hosting**: Zero cloud cost, but has unreliable availability (network changes, power outages) and requires in-house maintenance. May not provide enough reliability for production use. |
| 60 | +4) **AWS EC2 / GCP Compute Engine**: Very similar in terms of capabilities, not yet explored pricing and configuration process in detail. |
0 commit comments