I built hoist, a small push-to-deploy tool for one Linux box (systemd + Cloudflare Tunnel, Python stdlib). To keep myself honest I installed Dokploy on the same laptop and deployed the same Dockerfile app through both, polling the public URL every 50 ms:

• push to live, median of 6: 1.54 s vs 2.53 s
• downtime during swap: 0.00 s vs ~0.1 s
• broken build: old version keeps serving on both

The first run, hoist lost (0.65 to 1.45 s gap during rollover). The fix was a small TCP front that owns the public port and only switches once the new container answers HTTP. Method, raw logs and bugs found are in docs/benchmark.md.

One laptop, one competitor: a method, not a verdict. I'd like critique on the method more than the tool.

Built with AI assistance (Claude), designed and tested by me.

https://github.com/nikhilcherry/hoist

I'm working on a project split across several private GitHub repos. The ones that matter here are the Docker repo, the backend and an indexer. Each has its own .env files, and what's in them falls into three groups:

- Secrets like DB passwords, API keys and tokens

- Infra config such as private IPs of our fixed servers

- Backend tuning parameters we adjust depending on VPS size and load

Some fine gentleman on X posted this. "Not pushing .env files even to a private repo is like locking your front door but still keeping your valuables in a safe." I fully agree with that for secrets. They stay out of git, no debate there.

This is only about the config part. Having it in the repo would make DevOps work a lot easier. We'd get change history and PR review when someone tweaks a value, and no more copying files around by hand when setting up a server or onboarding someone.

My main concern is whether committing config-only .env files to a private repo is an actual security problem, or if "never commit .env" is really just about secrets. Also, is it a "security sin" to push a .env with private IPs? And how do you split secrets from config in practice, especially across multiple repos?

Thanks in advance!

instead of talking about idle hardware in theory, let me give you a specific headache we just hit. we have a local server with four 24gb cards.

two of those cards are locked up hosting two different low frequency models. one runs a fine tuned llama 3 8b for a background data extraction job. the other runs a qwen model for an internal bot. they get maybe fifty requests an hour combined. but because the weights just sit there taking up vram, two entire cards are held hostage doing almost nothing all day.

now we need to spin up a heavier 70b model for a new coding workflow, and suddenly we have no free cards. i look at the vram occupation in gpustack and see those two low traffic models just wasting dedicated space. so now i have to reallocate resources. i can either ask for budget to buy more hardware, or i try to pack both of those low frequency models onto a single card so i can free one up for the 70b.

what do you all do when you hit this wall? do you just keep dedicating specific cards to specific models to avoid the headache, or do you actively co-locate low traffic models onto the same gpu? when do you stop throwing money at new hardware and start packing your models tighter?

With so many different syntaxes and configs in our daily stack—CI/CD pipelines (GitHub Actions, GitLab), Terraform modules, Kubernetes manifests, Dockerfiles, Ansible playbooks, and Bash scripts—nobody can memorize every block and flag from scratch.
My current workflow is to use AI or existing templates to generate the initial boilerplate for Terraform resources, pipeline YAML, or K8s manifests, and then manually write, wire up, and audit the core architecture, state management, IAM/permissions, networking, and security logic.
For those working in production environments (and those running technical interviews):
1. In your day-to-day work, what parts of the stack do you still write completely by hand vs prompting an LLM or pulling from docs?
2. Where has AI actually helped you across Terraform, CI/CD, and K8s, and where does it consistently break things?
3. What is the realistic expectation in interviews right now regarding writing configs from memory vs understanding the underlying systems and debugging?