DevOps, CI/CD, and infrastructure — without the zealotry.
Infrastructure your future sysadmin will actually be able to maintain. No 40-line Helm charts under a small site, no microservices for the sake of microservices. Docker, simple CI, sensible monitoring, runbooks in the repo. It works — and keeps working after we're gone.
§ 09.1 What we do
Automated builds and deploys
GitHub Actions, GitLab CI, or your own runner — to fit your git. Tests, linting, build, deploy, rollback. None of the "push to main and hope for the best."
Containerization
Dockerfile, compose for local dev, production images. Multi-stage builds, slim final images, fast roll-outs.
K8s — when it's needed
For applications that genuinely need orchestration: autoscaling, rolling updates, blue-green, canary. For smaller projects, Docker Compose on a single server is cheaper and simpler.
Provider-to-provider moves
From AWS / GCP / DigitalOcean / Heroku to Hetzner / Selectel / Yandex Cloud — and back. Database migration without downtime, DNS cutover, verification, rollback if anything goes wrong.
Monitoring and alerts
Prometheus + Grafana, Loki for logs, Sentry for errors. Alerts to Telegram, prioritized incidents. So problems aren't first noticed by your customer and only later by you.
Infrastructure as Code
Terraform, Ansible, Pulumi. The whole infrastructure in git: reproducible, reviewable, reversible.
§ 09.2 Providers and stack
Default: Hetzner (cheap and reliable for European projects), Selectel / Yandex Cloud (for Russian ones), Cloudflare (CDN, R2, Workers).
Sometimes: AWS, GCP, Fly.io, Railway, Vercel — when the task plays to their specific strengths.
What we avoid: Heroku (too expensive), bare FTP (insecure), "let's just toss it on a Linux server and never update it" (a time bomb).
§ 09.3 Principles
- Infra complexity should match team size. Kubernetes for a two-person team is overkill.
- Every change goes through code and a pull request. No SSHing into prod to "fix it real quick."
- Backups get checked regularly. "We make backups" and "we know how to restore" are two very different things.
- Monitoring is set up before launch, not after the first data loss.
- Runbooks are written at setup time, not "we'll document it later."
§ 09.4 FAQ
We've been told we need Kubernetes. Do we?
Almost certainly not, if you have fewer than ten services and fewer than twenty requests per second. Docker Compose on one or two VMs solves the same problem at 10% of the time and money. We'll honestly tell you when k8s is justified.
Can we move from AWS to something cheaper?
Usually — yes. AWS is often 3–5× more expensive than Hetzner or Selectel for comparable hardware. We compute your current cost, scope the migration, and decide whether it's worth it. Sometimes it isn't.
Who maintains this after you leave?
Anyone who knows Docker and git. Configuration lives in the repo, runbooks in the README, no "secret scripts" on our laptop. The handover takes a couple of hours.
Our site is down. Can you do a one-off?
Yes, if the task is clear. "Site is down, no idea why" — we take it on, diagnose, fix, document. A one-off incident is a perfectly normal engagement.
Tell us
what's hurting right now.
hi@weiss.help ↗
First 20-minute call — free. Critical incident — we take it on the same day.