Skip to main content

max / makenotwork

3.7 KB · 118 lines History Blame Raw
1 # Infrastructure
2
3 How we choose, run, and manage the services that power Makenot.work.
4
5 ## Philosophy
6
7 We self-host where practical. Every vendor is a dependency, a potential point of failure, and a cost passed to creators. When we do use external services, we choose carefully.
8
9 ### Commodity Over Premium
10
11 We go with the cheapest reliable option, not the one with the fanciest dashboard.
12
13 ### No Lock-In
14
15 We avoid services that make it hard to leave:
16
17 - **Standard formats:** Data stored in formats that work anywhere
18 - **Exportable configurations:** Settings we can move to another provider
19 - **No proprietary APIs:** When possible, we use providers that implement open standards
20 - **Multi-provider capability:** Critical infrastructure can run on multiple vendors
21
22 If a provider doubles their prices or changes their terms, we can move.
23
24 ### Open Source Where Possible
25
26 We prefer open source for software we run ourselves. Managed services sometimes make sense, but open source is the default.
27
28 ### Cost Transparency
29
30 We can explain every line item in our infrastructure bill. See the economics documentation for the breakdown.
31
32 ---
33
34 ## Production Stack
35
36 ### Hetzner
37 - Application server + PostgreSQL: VPS in US-West (Oregon)
38 - Object storage (S3-compatible), in the EU: user files in Germany, SyncKit blobs and OTA artifacts in Finland
39 - Backup: bucket versioning enabled
40 - Exit: standard S3 API, portable to any S3-compatible provider
41
42 ### PostgreSQL
43 - Self-hosted on Hetzner VPS
44 - Daily backups with 30-day retention
45 - Offsite backup replication to a separate machine on personal hardware in a different location
46 - No external managed service dependency
47
48 ### Stripe
49 - Connect (creators onboard directly)
50 - Creators keep their Stripe accounts if they leave
51 - Exit: roadmap item (no backup processor integration yet)
52
53 ### Postmark
54 - Transactional email (password reset, verification, receipts)
55 - Exit: self-hosted migration when scale justifies
56
57 ### Fastmail
58 - Business email (support@, legal@, max@)
59 - Exit: self-hosted migration when scale justifies
60
61 ### Cloudflare
62 - DNS management
63 - CDN for static assets and edge caching
64 - DDoS protection
65 - Free tier sufficient initially
66
67 ### Domain Registrar (Cloudflare)
68 - All domains registered and managed through Cloudflare
69
70 ---
71
72 ## Why These Choices
73
74 **Hetzner over AWS/GCP:** 80% cost reduction, US and EU regions available, no vendor lock-in.
75
76 **Self-hosted PostgreSQL over managed:** No external dependency, full control over configuration and backups.
77
78 **Stripe Connect:** Direct payouts to creators without us touching funds. PCI compliance handled entirely by Stripe.
79
80 **Cloudflare:** Free tier covers most needs.
81
82 ---
83
84 ## Redundancy
85
86 - Database: Daily automated backups (30-day retention)
87 - Files: Bucket versioning on object storage
88 - Application: Single-server today; load balancer planned at scale
89 - DNS: Cloudflare's anycast network
90
91 ## Monitoring
92
93 Handled by PoM, a self-hosted production operations monitor we built. See [Monitoring]./monitoring.md for details.
94
95 ---
96
97 ## Cost Philosophy
98
99 Infrastructure costs scale sub-linearly with creator count. We optimize for cost-efficiency, not impressive-sounding tech stacks.
100
101 ---
102
103 ## Trade-offs We Accept
104
105 Doing things the hard way has costs:
106
107 - **More operational work:** Self-hosted infrastructure means maintaining it
108 - **Slower feature development:** Time on infrastructure is time not on features
109 - **Learning curves:** Open source tools don't always have great documentation
110
111 The alternative (expensive vendor lock-in with costs passed to creators) is worse.
112
113 ## See Also
114
115 - [Architecture]./architecture.md: system design and components
116 - [Security]./security.md: how we protect data
117 - [Monitoring]./monitoring.md: PoM and the health endpoint
118