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?

I’m just wondering if people still are with them and if they switched. Would love to know where you guys switched if u did

Evaluating CD tools to automate our end to end delivery (build, test, packaging, and deployments). Curious if the standard GHA + Argo/Flux combo is still what most teams stick with, or if there are dedicated delivery/orchestration tools actually worth looking at in 2026.

I'm looking for some architectural advice on building a lightweight, self-hosted job execution platform on a single VM (8C/32GB).

I want something with semantics similar to Google Cloud Run / Cloud Run Jobs:

• Execute Python scripts and arbitrary Docker containers.
• Trigger jobs through an API.
• Configure CPU, memory, environment variables, timeouts, etc.
• Track execution status, exit codes, and logs.
• Handle retries and concurrency limits.
• Integration with Artifact/Container Registry

Current constraints:

• Only one VM for now & no need for HA.
• No Kubernetes requirement or plans for a multi-node cluster.
• Jobs are primarily internal workloads, and quite lightweight.
• I'd prefer something relatively lightweight and easy to maintain.

Technologies I'm considering

1. HashiCorp Nomad
2. Docker Sock + custom built runner – Build my own execution manager, scheduling, lifecycle management, and monitoring.

Questions

1. Is Nomad overkill for a single VM? Does it provide enough value over simply using Docker directly?
2. Would you use Nomad in production for this use case?
3. Are there simpler alternatives that provide similar execution semantics?
4. What operational overhead should I expect from running Nomad on a single node?

I'm particularly interested in hearing from people who have actually run Nomad in production, especially for single-node deployments.

Thanks!

With the recent high-stakes security exploits, I think as DevOps engineers it's our responsibility to make the local dev environment secure for devs.

What do you think?

What are you actively doing about it (like adopting devcontainers)

I could use some advice on a situation at work.
A few colleagues in ops have, almost overnight, started to fully trust their LLM agent because it has gotten so good lately and "doesn't make mistakes anymore". They built their own harness around it and log what it does (using Grok and Google models), but the agent still runs with root access to our entire production infrastructure. We have no clear team rules or policy yet, and they don't see the danger themselves.
A typical example: whenever the agent needs to check something on a server, they just hand it full access. But looking at info only needs read-only access. The permission should match the task, not the most convenient option.
My concerns:
Logging is detection, not prevention. It shows what broke afterwards, but doesn't stop anything.
Root bypasses the harness. An agent with root can in theory edit the harness, the logs and the backups, so those logs are not a reliable audit trail.
No least privilege. One wrong command or misread context can touch everything.
Prompt injection via logs, tickets or web pages the agent reads.
Model updates. Providers change models without us deciding when, so "no mistakes in recent months" says little about the next version.
Data going to third parties. With root, the agent can read .env files, keys and customer data, which then end up with the model provider (a GDPR question too).
"It has gone fine so far" only means the failure hasn't happened yet.
I don't want to ban anything. I want them to see the risk themselves and set up proper guardrails together with me: a read-only user by default, scoped credentials, just-in-time access, human approval for write actions, staging first, and no access to backups and logs.
Questions for you:
How do I explain the difference between "we log it" and "it can't do it in the first place"?
How have you convinced overconfident colleagues about AI tooling risks without a confrontation?
Do you have horror stories or post-mortems I can share? Concrete incidents tend to work better than theory.
Which guardrails or policy examples have worked well for you?
How do you raise this with management without coming across as "anti-AI"?

Hi,

Im now in the beginning of devops journey and I'm not really a reader person but I want to spend my free time in something useful so any suggestions for a book would help in my career and will benift me.

In case any of you use OpenSSH on musl without PAM:

https://sshhole.com/

TL;DR: Accounts that should never take a password at all (root, your key-only deploy user, ldap users, the default user on alpine's aws and azure images) take any password longer than 256 characters.

We use several external APIs and I’m curious how often other teams out there keep performance tests realistic and structured while accounting for third party dependencies. How do you balance realistic dependency behavior with controlled and repeatable tests? Things are going well overall (but they could always be better) and I want to make sure my team and I aren’t missing something that could be beneficial.

Sharing my views , seniors can correct me.

Python

(It will give max advantage i believe, it's programming language as well so I can say I know programming as well, If I want to switch to data science, ai ml or any other field then it can help me, I know basic of it and find it interesting)

Go

(It will help me in understanding Kubernetes in a better way, again programming language so It will be amazing to have skill, don't know much where it will help me but yes, I haven't learned this ever so I will be excited for this)

Shell/bash

(Core skill listed in almost every devops job but again I feel like it will be truly limited to automation and I don't find it very easy to learn, very weirds and long braces, dots and what not )

TLDR; working as a junior in a big team, just doing ops task and not improving enough. how should i spent my free time and navigate my career?

hi all, i know this is probably a recurring discussion, ive tried searching for similar one but i still am not satisfied with the answers.

im a freshgrad with previously 1yoe remote work as devops engineer in a team that only consist of 8 softeng (im the only devops there), honestly its great because i feel like im owning things and can improve things left and right. but, i lack mentorship and feedback there (also low salary lololol) and feel like theres no growth

now, thankfully im in a better and mature company where the devops team itself has more than 50 people. im only a junior here and still in a probation phase, so my day to day are mostly just exploring our services and doing nothing.

what should i do? do i just do thing slowly? i feel like im left behind in this era of AI where people are building things and i just feel like im not enough if all i do is working on ops task and not owning anything. i do learn things on my free time but thats all, feel like its never enough. thanks!

Hey fellow DevOps folks! I've been wrestling with secrets management recently. I set up a tool that generates API keys, but every time I think I've got it right, I find myself second-guessing whether they’re genuinely secure! 😅 There was this one time I accidentally committed sensitive info to Git—ugh, the panic! Luckily, I caught it fast, but it got me thinking: What strategies or tools do you all lean on for managing secrets? Do you prefer something like HashiCorp Vault, or are you more into environment variables? Let’s share some tips and tricks! What’s been your experience with it?

I'm working in a startup. Recently there was a layoff as well. Around 10% was removed.

The thing is this. Within like 8 months, our microservice count is trippled. But the same DevOps team. Even with the layoffs, new developers are hired. Requirements are coming very fast and it's difficult to work on Platform Building, Service Provisioning, Ops work all at once.

We have like unlimited AI. But eventhough it takes time to analyse the requirements, review the designs and implement the solutions.

Currently I'm just asking the AI to raise the PR and just rushing through it and applying the changes.

The problem is that, it's feel like I'm just tired and doing a labour work.

I'm not actively learning anything because of the fast pace and high workload.

Should I look for a new job?

Is other places like same due to the AI?

Update: Thanks redditors. I see that I'm not alone. Seems everywhere is like this.

Just went back to Railway's status page after the Oct 21–23 outage. The main “Railway” uptime chart now says 100.00% for the last 90 days.

Couldn't access the dashboard, couldn't build anything. Apparently that's 100% uptime. Their own incident updates said builds were paused across every region, and Wayback saved the outage announcement.

The October 30 snapshot shows that same “Railway” chart at 97.10%. Now it's 100.00%. The outage is still inside both 90-day windows.

Support & Community used to sit inside that group. Now it's listed separately, still at 97.10%, while “Railway” gets to show a perfect 100%. Very convenient.

The dashboard and API charts were already showing 100% in the old snapshot, despite their own updates saying those services were unavailable. So those numbers never reflected the outage either.

Yes, the incident is still under History. But if I have to dig through incident logs to find the downtime behind your 100% uptime chart, what the hell is the chart for?

I've been speaking to recruiters recently about roles in my area.
Almost every set of interviews now has a live coding portion to it.

I've got an interview next week where I've been told I will be asked to live code. When asked what sort of coding, I was told - it could be writing Terraform, Python, writing a helm chart, kubernetes manifests. It will be random on the day.

I've individually done a lot of these. I've been writing Terraform for years, and I do Kubernetes manifests every single day.
However, I might not touch Terraform for months whilst I work on one project. Python might be even longer.

If tasked with a Terraform project, I'll look at some recent work I did, get a feel for it again, and I'm productive pretty quickly.
But just throw me into an interview, and have multiple engineers ask me to live code, and I feel like I would turn to jelly. I can't remember off the top of my head how to do a module for Terraform - give me a previous one I created, I can take it as a template and start rewriting it, looking up functions if I need new things.

Same for Kubernetes. I will take a deployment file and a svc I did for something in the past, copy and paste it into a new file and edit it to fit my new needs. Writing the document from scratch without documentation... I can't remember that for shit. Who does it afresh on every new service?

We often talk about securing the software supply chain in terms of application dependencies. For instance, pinning package versions, maintaining lockfiles, and auditing third-party libraries.

But what about the code that runs our CI/CD pipelines?

GitHub Actions workflows can execute third-party actions, and the security of those dependencies matters just as much when building and deploying software.

The introduction of workflow dependency lockfiles is an interesting step towards making CI/CD workflows more reproducible and secure.

I wrote about this recently, exploring why workflow lockfiles matter and how they fit into the broader software supply-chain security picture.

Read the article: https://amitmerchant.com/ci-pipeline-lockfile/

Curious how others are approaching dependency security in their CI/CD pipelines. Are you already pinning your actions and enforcing similar controls?