Built with thought.
Shared as we go.
Why Hakopod works the way it does. Notes on the choices behind the product, and practical lessons for running the things you build.
What MyDuck’s two SQL protocols actually mean
How one DuckDB database serves MySQL and PostgreSQL clients, where compatibility stops, and what the managed release does and does not provide.
Read the story↗Engineering
01 / FROM THE HAKOPOD WORKBENCHWhat Hakopod’s Managed Vitess release runs
A concrete look at Vitess shards, routing, private TLS, native backups, recovery and the limits of the first release.
Read the story↗How Hakopod manages a database
The path from a database configuration to durable operations, native controllers, verified connections and a reviewed recovery.
Read the story↗Read a database topology before you trust it
What replicas, shards, endpoints and connected applications tell you about a database, and what a diagram cannot prove.
Read the story↗Let a quiet HTTP service sleep
Scale-to-zero is useful when the waiting is acceptable. Here is how to decide which services should sleep.
Read the story↗Pinning a service is a tradeoff
An exact node can be the right place for a workload. It also changes what happens when that machine goes away.
Read the story↗Which commit is in that container?
An image tag is a convenient name. Connecting an external CI build to a release takes a more precise record.
Read the story↗A small platform needs limits
Queues, log windows and background work all consume the server you brought. Bounded work is part of the product.
Read the story↗Security
02 / FROM THE HAKOPOD WORKBENCHProduct
03 / FROM THE HAKOPOD WORKBENCHStart small. Keep your options.
The idea behind Hakopod: make the first deployment approachable, and let the next decision wait until your application needs it.
Read the story↗Where Hakopod Cloud stops
Git deployments and private services fit shared hosting. Owning public SMTP, SFTP and custom TCP listeners calls for a different operating model.
Read the story↗Operations
04 / FROM THE HAKOPOD WORKBENCHA request is a good place to start
When an HTTP endpoint fails, start with the request that reached it. A practical tour of Requests and routing in Hakopod.
Read the story↗A deploy notification should tell you what happened
Send deployment results to email, Slack, Discord or a webhook, and check whether delivery succeeded.
Read the story↗Rollback is not a database restore
An old image can fix a bad release. It cannot undo a schema migration or bring back deleted rows. Plan both kinds of recovery.
Read the story↗Your first restore should be a rehearsal
A backup becomes useful when you know how to recover from it. Try the recovery path before an outage chooses the timing.
Read the story↗A green deploy is the start of verification
Build success, release readiness and a working user flow answer different questions. Keep each piece of evidence in view.
Read the story↗Networking
05 / FROM THE HAKOPOD WORKBENCHDeployment
06 / FROM THE HAKOPOD WORKBENCHField notes
07 / FROM THE HAKOPOD WORKBENCHA template is the start of a decision
A useful preset gets you past a blank file. You still need to review the workload it is asking your server to run.
Read the story↗Give your team a project, not a shared login
Small teams need understandable access boundaries from the start. Sharing an administrator password makes those boundaries disappear.
Read the story↗