max / makenotwork

3.6 KB · 117 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	- VPS (US-West) + S3-compatible Object Storage
38	- Backup: bucket versioning enabled
39	- Exit: standard S3 API, portable to any S3-compatible provider
40
41	### PostgreSQL
42	- Self-hosted on Hetzner VPS
43	- Daily backups with 30-day retention
44	- Offsite backup replication to a separate machine on personal hardware in a different location
45	- No external managed service dependency
46
47	### Stripe
48	- Connect (creators onboard directly)
49	- Creators keep their Stripe accounts if they leave
50	- Exit: roadmap item (no backup processor integration yet)
51
52	### Postmark
53	- Transactional email (password reset, verification, receipts)
54	- Exit: self-hosted migration when scale justifies
55
56	### Fastmail
57	- Business email (support@, legal@, max@)
58	- Exit: self-hosted migration when scale justifies
59
60	### Cloudflare
61	- DNS management
62	- CDN for static assets and edge caching
63	- DDoS protection
64	- Free tier sufficient initially
65
66	### Domain Registrar (Cloudflare)
67	- All domains registered and managed through Cloudflare
68
69	---
70
71	## Why These Choices
72
73	Hetzner over AWS/GCP: 80% cost reduction, US and EU regions available, no vendor lock-in.
74
75	Self-hosted PostgreSQL over managed: No external dependency, full control over configuration and backups.
76
77	Stripe Connect: Direct payouts to creators without us touching funds. PCI compliance handled entirely by Stripe.
78
79	Cloudflare: Free tier covers most needs.
80
81	---
82
83	## Redundancy
84
85	- Database: Daily automated backups, point-in-time recovery
86	- Files: Bucket versioning on object storage
87	- Application: Single-server today; load balancer planned at scale
88	- DNS: Cloudflare's anycast network
89
90	## Monitoring
91
92	Handled by PoM, a self-hosted production operations monitor we built. See [Monitoring](./monitoring.md) for details.
93
94	---
95
96	## Cost Philosophy
97
98	Infrastructure costs scale sub-linearly with creator count. We optimize for cost-efficiency, not impressive-sounding tech stacks.
99
100	---
101
102	## Trade-offs We Accept
103
104	Doing things the hard way has costs:
105
106	- More operational work: Self-hosted infrastructure means maintaining it
107	- Slower feature development: Time on infrastructure is time not on features
108	- Learning curves: Open source tools don't always have great documentation
109
110	The alternative (expensive vendor lock-in with costs passed to creators) is worse.
111
112	## See Also
113
114	- [Architecture](./architecture.md): system design and components
115	- [Security](./security.md): how we protect data
116	- [Monitoring](./monitoring.md): PoM and the health endpoint
117