Uses

• MacBook (Apple Silicon) — the operator workstation; most real work happens over SSH from here
• Linux VPS — a small, reproducible remote environment for projects and experiments
• Self-hosted Docker — disposable, repeatable environments for testing and deployment

• macOS locally; Ubuntu on the servers that matter
• Terminal-first, SSH-heavy — most operations happen on remote hosts, often under load
• A minimal-dependency setup, so it behaves the same on a laptop or a jump host
• VS Code for editing
• Git for anything that changes

• Oracle Exadata, RAC, Data Guard, ZDLRA — platforms where availability and recovery are the work
• OEM and observability tooling — seeing state before it turns into an incident
• Docker, Nginx, Cloudflare — reproducible deployment and a smaller exposed surface
• Spring Boot / Java — services that have to behave predictably
• Redis, PostgreSQL — data stores with well-understood failure modes
• Linux administration and troubleshooting — the layer everything else rests on

• Cloudflare Access — identity-gated routes with the origin locked down
• Explicit trust boundaries and reduced exposure by default
• Client-side encryption — keys and plaintext owned locally, not by the server
• XChaCha20-Poly1305, Argon2id
• Designs that minimize unnecessary trust rather than add controls afterward

The day-to-day is troubleshooting, reducing ambiguity, and keeping systems understandable while they are under stress. Most decisions come down to operational clarity and recovery: fewer moving parts, predictable behavior, and a defined way back when something fails.

Automation — including assistive tooling — earns its place only inside explicit boundaries, where it removes friction without becoming another thing to debug at 3AM. The preference is for systems that are observable, resilient, and minimal over ones that are only theoretically complete.