DEV Community: Idlefy

We Build a Digital World, Then Dream About a Garden

Tetiana Anisimova — Mon, 28 Sep 2026 15:27:13 +0000

I want to talk about why people who spend years building digital systems eventually start dreaming about a house in the countryside, a vegetable garden, a farm, or a small restaurant.

There is a strange thing I’ve been noticing more and more among people in IT.

First, you want to build a career. Then you want a good salary, interesting projects, remote work, a Senior position, then Lead, Architect, or Engineering Manager. And after a few years, you start dreaming about a house on the edge of a village. A few garden beds or a small cheese farm.

Some people start growing vegetables on a small plot of land. Some dream of opening a bakery or a restaurant. Some actually buy land and move out of the city.

And I think there is much more to it than simply wanting to leave the city.

After years of digital work, we start missing reality

Programmers, DevOps engineers, SREs, data engineers, analysts, and many other technical professionals spend a huge part of their lives in a world that cannot be touched.

We work with code, APIs, databases, cloud infrastructure, logs, charts, tickets, and metrics. We can spend an entire day creating something incredibly complex and then, in the evening, have this strange feeling that we didn’t actually accomplish anything important.

You wrote hundreds of lines of code, but you can’t see them as an object you can touch. You fixed production, and a few hours later, nobody is thinking about it anymore. You optimized a system, and the best result of your work is that nothing happened. The server didn’t crash. The request became faster. The infrastructure bill went down. The user simply continued using the product.

We’ve learned to consider things nobody notices to be a good result.

And that’s perfectly normal for good engineering. But sometimes people want a completely different feeling.

They want to walk outside in the evening and see that something real has grown during the day. Touch the soil. Pick a few cucumbers. Fix an old chair. Knead some dough. Make cheese. Build a table.

And then look at it all and think: I made this with my own hands, and here it is.

Not in a browser. Not in a dashboard. Not in Jira.

Here.

We’re drawn to tangible results.
In digital work, almost nothing ever truly ends.

There is the next release, the next bug, the next incident, the next version, the next framework, and the next technology. You have to keep learning something new, because what you knew yesterday is already becoming outdated. And so the cycle continues, an endless race.

Even when everything works, there is always another question. Can we make it faster? More reliable? Cheaper? More elegant? More secure? More scalable?

Now imagine a vegetable garden.

You planted the seeds. You watered them. You waited. The first sprout appeared. Then a flower. Then a small green cucumber. A few weeks later, you picked it and put it on the table. You ate it.

That’s it.

No next sprint. No urgent ticket. No production incident. The cucumber simply grew.

Maybe this is one of the most underestimated things in modern life. Sometimes we don’t want another achievement. We want the feeling that something has actually been completed.

Burnout plays a huge role. And it’s not just about working too much.

Burnout is often discussed as a consequence of overwork. But research shows that the picture is much more complicated. It involves workload, autonomy, support, a sense of fairness, psychological safety, the quality of relationships, and how well the work itself aligns with a person’s own values.

The situation in technical professions is particularly interesting because the complexity of the work almost never ends. Tools, architectures, technologies, business expectations, and now even the development process itself are changing because of AI.

According to the Engineering Leadership Report 2026 from LeadDev, based on responses from more than 600 engineering leaders, 45 percent of respondents are working more hours per week than they were a year ago. Among software engineers, 40 percent reported feeling emotionally drained at least once a week, and among engineering managers the figure rises to 49 percent.

This no longer looks like a problem affecting just a few overworked people.

When almost half of professionals regularly experience emotional exhaustion, the issue is probably not only about an individual’s ability to cope with stress.

There is another interesting detail. More than 49,000 developers from 177 countries participated in the Stack Overflow Developer Survey 2025. Only about a quarter of developers said they were happy at work. Among the factors they considered important for job satisfaction were autonomy and trust, competitive compensation, and the ability to solve real problems.

Press enter or click to view image in full size

That last point is particularly interesting.

Solving real problems.

Not abstract ones. Not endless technical debt. Not another layer of a complex system.

Real ones.

When KPIs take over an engineer’s everyday life

Engineering teams have long relied on a huge number of metrics. Deployment frequency, lead time, reliability, error rates, recovery time after failures, performance, infrastructure costs, and many other indicators help organizations understand how engineering is performing.

Metrics themselves are useful. The problem begins when a person starts feeling that they have to be faster, more productive, cheaper, more stable, and constantly learning something new — all at the same time.

It becomes an almost perfect pressure machine.

You have to write more.

Make fewer mistakes.

Learn new technologies.

Use AI.

Solve problems faster.

Maintain legacy code.

Keep an eye on security.

Understand the business.

And ideally do all of this while continuing to increase team productivity.

At some point, a person stops feeling like they are simply doing their job. They start feeling like they are constantly having to prove their worth.

And that’s when the idea of a few garden beds can suddenly become surprisingly appealing.

People who made the leap

From Google to the land and food
In 2022, Mantaj Sidhu, who had spent almost five years working at Google, left the company and moved back from Dublin to Punjab. There, he started working in organic farming and later became a co-founder of the farm-to-table project Gill Organics.

Back in India, he made a very literal choice. He wanted to work with the land, grow food, and solve a problem he could directly see and feel in his own life. I want to share a couple of his thoughts on the subject:

“I wanted to step into the real world, apply my skills to solve a tangible problem, and derive a sense of achievement from genuine impact rather than a title or paycheck.”

“Today, the personal income in my bank account may be leaner, but the time, energy and focus I invest belong entirely to me.”

From Meta to noodles
Alvin Tan’s story is an even starker contrast. He worked as a software engineer at Meta, but eventually left his high-paying career and started selling traditional Singaporean Hokkien Mee with his girlfriend at a small food stall.

The reason he gave sounds almost absurdly simple:

“Because software engineering is boring.”

Another form of creation

We are used to thinking that professional development should always go upward.

Junior becomes Mid-level. Mid-level becomes Senior. Then Lead. Then Manager. Then Director.

Every next level means more responsibility, more money, and more people expecting something from you.

But human life doesn’t quite work that way.

Sometimes the next stage of growth is not more complicated work, but a simpler life.

A person can spend ten years building complex systems and then want to build a greenhouse.

They can spend their entire career optimizing processes and then start baking bread.

They can manage a team of dozens of engineers and then dream about a small twenty-table restaurant.

They can spend their days working with cloud infrastructure and their evenings searching for information about how to grow strawberries.

And there is nothing illogical about that.

Quite the opposite.

We simply want to feel human again

Technology is wonderful. Creating software really is amazing. We can imagine something that didn’t exist yesterday and, in a short amount of time, make it work for thousands or millions of people.

But there is a downside to that ability.

When you live in the digital world for too long, physical reality starts to feel almost like a luxury.

The smell of soil after rain.

Warm bread.

The wooden surface of a table beneath your palm.

The sound of rain on the roof.

Apples from your own tree.

Chickens in the yard.

A vegetable garden that cannot be updated with a single prompt.

There is something deeply calming about things that cannot be sped up.

A seed doesn’t know about your deadline. Cheese won’t be ready sooner because you have a quarterly review today. A tree won’t release a new version on Monday. And maybe that’s exactly why all of this is so appealing.

A little slower, please

We created technology to get work done faster. We created automation so we wouldn’t have to repeat the same things. We created AI to accelerate intellectual work even further. We created systems that run around the clock.

And then we started living as if we were supposed to work around the clock too.

Maybe that’s why, after ten or fifteen years in IT, a person starts looking at the land with completely different eyes. Not necessarily because they are tired of technology. Not because they failed.

Simply because, at some point, it becomes important to create something that exists somewhere beyond the memory of a computer.

Something you can grow.

Something you can cook.

Something you can build.

Something you can take care of.

Something that needs time.

And something whose result you can see with your own eyes.

One of the simplest things we miss in adult life.

Sometimes we want a world where our value isn’t measured by how much work we have completed. A world where the result can be touched. A world where we don’t have to constantly improve.

We can simply be.

And feel the ground beneath our feet.

Being Good at Your Job Is No Longer Enough

Tetiana Anisimova — Mon, 21 Sep 2026 06:41:26 +0000

The tech job market has changed. So has the definition of an engineer a company really wants to keep.

There’s a fairly simple way to understand how much the tech job market has changed.

Talk to someone who has been watching it long enough.

While working on this article, we spoke with an HR Director we know - someone with 15+ years of experience across IT and technology businesses.

Over the years, she has been involved in thousands of hires, from junior roles to senior technical experts and executives. But recruitment is only part of the picture. Her experience spans performance management, compensation, team building, restructuring, retention, terminations, and the countless HR and operational processes that rarely make headlines but often determine how strong a business actually is on the inside.

We asked her what she’s seeing in the technical talent market right now.

“I have never received this many messages from strong senior technical professionals asking me to help them find a job. Never.”

Not juniors. Not people who finished a bootcamp last month. Senior Engineers. DevOps Engineers. Technical Leads. People with serious experience.

A few years ago, companies were chasing them. Today, some of them are messaging HR leaders on LinkedIn: “If you hear of anything, let me know.”

The world has shifted.

And it’s not just one HR Director’s anecdotal experience.

After the massive tech hiring boom, the market went through several years of layoffs and slower hiring. In 2025, Indeed reported that even senior and management tech job postings in the US remained well below their 2022 peak, while employers were increasingly raising experience requirements.

In 2026, software development hiring finally started showing signs of recovery. But there’s an interesting detail.

71% of the growth in software development job postings between May 2025 and May 2026 came from senior roles.

So this isn’t a story about engineers suddenly becoming unnecessary. It’s more interesting than that.

Companies are still willing to pay for strong technical talent. They’re just becoming much more careful about what, exactly, they’re paying for.

And that changes the game.

Being a good engineer used to be enough

Let’s exaggerate a little.

You’re a Senior DevOps Engineer.

The infrastructure works. Deployments happen. The pager doesn’t scream every night. AWS isn’t on fire. At least not literally.

You deliver your work, support developers, resolve incidents, and know several terrifying things about production that are probably best left undocumented.

You’re good at your job. A year passes. Performance review time.

I delivered.
My feedback is good.
Inflation was X%.
I think it’s time to revisit my compensation.

Reasonable. And not that long ago, that was often enough to start the conversation.

Today, there’s another question increasingly appearing on the other side of the table:

“What did the business actually get from your work this year?”

That’s a less comfortable question. Especially because “Well… the infrastructure works.” is a perfectly valid technical answer.

It’s just not a particularly informative financial one.

Doing good work and creating measurable value aren’t exactly the same thing

Engineering culture has traditionally measured seniority through technical complexity.

What systems can you build? What scale can you handle? How complex an incident can you untangle? How quickly can you find the problem everyone else has been staring at for six hours?

None of that is going away.

But another dimension of seniority is becoming increasingly important:

Do you understand which technical decisions cost the business money?

Not just how much RAM a service consumes. How much the company pays for that RAM.

Not just whether an architecture can scale. Whether the business should be paying for that scale in the first place.

Not only: “How do we fix this?”

But occasionally: “Why the hell are we paying for this at all?”

The new seniority isn’t only about solving harder technical problems.

It’s about understanding which technical problems show up in the company’s numbers.

Meet two Senior DevOps Engineers

Same level. Comparable compensation. Both reliable. Both technically strong.

Engineer #1 receives tasks and executes them well. Ticket appears. Ticket gets picked up. Ticket gets closed. Infrastructure works. Everyone’s happy.

Engineer #2 does all of that too. But one day, they notice something else.

Dozens of dev and test environments keep running at night. And on Saturday. And Sunday. And for a surprising number of hours when their main purpose appears to be making AWS money.

They could drop a message in Slack: Guys, looks like we’re wasting some money here. And move on.

Instead, they dig deeper. They look at usage. They identify idle hours. They calculate the cost. They estimate the savings opportunity.

And then they go to the CTO. Not with: “I found a cool tool.”

But with:

This infrastructure currently costs us €X per year.
Roughly €Y of that appears to be spent during hours when nobody is using it.
Here’s how we can automate it.
Here’s the cost.
Here are the risks.
Here’s the potential ROI

A few months later, the company is saving money. Actual money.

Not story points. Not closed Jira tickets. Not an impressive dashboard. Money.

Then that engineer finds another optimization opportunity. And another.

Now imagine a less pleasant quarter. The owner says: “We need to cut engineering costs by 15%.”

The CTO has two Senior DevOps Engineers. One is a good engineer. The other is a good engineer who found ways to save the company tens of thousands of euros over the past year - and keeps finding more.

Suddenly, the conversation looks a little different.

Nobody is truly unfireable

No list of career hacks can guarantee anyone a job.

You can be an exceptional engineer and still get laid off. A company can shut down a product. Move a team. Automate a function. Run out of money. Get acquired. Change strategy. Things happen.

But there is a huge difference between being irreplaceable and being expensive to lose.

The first is mostly a myth. The second is absolutely achievable.

Start thinking like more than an engineer

We’re not suggesting that every DevOps Engineer should open Excel tomorrow morning and declare themselves CFO. Please don’t.

We’re suggesting something simpler. Every once in a while, look at technology through the eyes of the person paying for it.
Where are we losing money?

What are we paying for that nobody is using?
What could be automated?
Where has technical debt become financial debt?
What could we make cheaper without hurting reliability?
What keeps consuming engineering time?
What are we doing manually over and over again?
Where could a technical decision improve margin, speed, or revenue?

And, most importantly: Can I prove it with numbers?

That’s where a different kind of seniority begins.

Engineering is getting closer to the P&L

This isn’t just a nice theory.

The State of FinOps 2026 report draws on 1,192 respondents from organizations representing more than $83 billion in annual cloud spend.

The direction is clear. FinOps is moving beyond simply explaining where the money went. It is increasingly involved in deciding where technology money should go in the first place.

The conversation is no longer just about managing cloud cost. It’s about managing the business value of technology.

McKinsey, analyzing more than $3 billion in cloud spend, identified another 10–20% in potential savings across the organizations studied.

Think about that. 10–20%.

For a company spending €1 million on cloud infrastructure, that could represent €100,000–€200,000.

And some of that money may currently be sitting there at 3 a.m., quietly powering infrastructure nobody is using.

This changes the CTO’s job too

Now let’s look at the other side of the table.

Not that long ago, this was a reasonably survivable management model: If it works, don’t touch it.

Production is alive. Releases are shipping. The team looks busy. Headcount is roughly on plan. Great.

Today, owners, CEOs and CFOs increasingly want better answers.

Why does engineering cost this much? What got faster this year? What got cheaper? What did we automate? Where are the bottlenecks? Why did the cloud bill grow 30% if revenue grew 12%? What exactly do we get if we hire three more engineers?

And one of the hardest questions: What business value does the next €1 invested in technology create?

“Everyone seems very busy” is becoming a less convincing answer.

The “it works, don’t touch it” era is ending

For systems. And for teams.

More and more engineering activity can be connected to measurable data: cloud spend, resource utilization, idle time, deployment frequency, lead time, incident rates, MTTR, automation, infrastructure cost.

The economic impact of technical decisions is becoming easier to see.

Which means one of the most important responsibilities of a modern CTO isn’t simply building a strong engineering organization. It’s understanding the weight of that organization.

What does this function create for the business? What does this investment change? Where does a person create leverage? Where does a team save money? Where does it help make money? Where does it maintain something business-critical - which can be enormously valuable too, provided that value can be explained?

This does not mean turning every developer into a row in a spreadsheet.

It means engineering can no longer operate indefinitely as a black box:

€3 million goes in.
Technology comes out.
Please don’t ask follow-up questions.

That era is ending.

For engineers, visibility of value is becoming part of career resilience.

For CTOs, the ability to see and explain that value is becoming part of the job.

Fine. What can you actually do tomorrow morning?

Start with something boring. The bill.

Look at your non-production infrastructure: Dev. Test. QA. Staging. Demo environments.

How much does it cost? Now look at when people actually use it.

Say an environment is needed ten hours a day, five days a week. A week has 168 hours. You’re using it for 50.

Which leaves one fairly obvious question: What happens during the other 118?

If the answer is: “Well… it keeps running.” we have bad news and good news.

The bad news: you’re paying for it.

The good news: you’re paying for it.

Because now you know where to look for money.

And no, you don’t even have to calculate all of this yourself

At this point, we could give a Senior DevOps Engineer another project.

Export the usage data. Analyze the last month. Identify idle hours. Map them to instance types and regions. Calculate the cost. Rank the worst offenders. Build a business case. Make a presentation. Then try to steal half an hour from the CTO’s calendar.

Sounds fantastic. Especially for someone who clearly has nothing else to do.

So we already did the first part for you.

Idle Audit is free.

Connect AWS or Google Cloud in read-only mode, and Idle Audit analyzes the previous 30 days of usage data already collected by your cloud provider.

It installs nothing. Stops nothing. Changes nothing. And it doesn’t require a credit card.

What you get is much more useful than: “I have a feeling we’re wasting money somewhere.”

You can see how many idle hours were detected, their estimated cost, which specific instances created the most waste, their type and region, and a weekly hourly map showing when the waste actually happens.

So your first conversation with the CTO doesn’t have to begin with: “I think we might be able to save some money.”

It can begin with: “Here’s our own data. Take a look.”

That’s a very different conversation

The Audit finds the waste. Idlefy keeps it from coming back.

If the Audit shows there isn’t a meaningful opportunity, great. You spent a few minutes and got your answer. You do not need to buy Idlefy just because we built it.

But if the numbers are interesting, that’s where the second part begins.

Idlefy changes the default state of development infrastructure: stopped becomes the default.

Need a machine? An engineer starts it through Slack, Telegram, or the web for however long they need it.

Need more time? Extend the lease. Finished early? Release it. Forgot? When the lease expires, the machine stops automatically.

Not because some algorithm decided: “Hmm. Sergey hasn’t moved his mouse for a while. Shut down production.”

No. The engineer decides how long the resource is needed.

Idlefy simply makes sure “I’ll remember to shut it down later” is no longer part of your cloud cost strategy.

But the savings are only half the story

Remember where we started? Creating value matters. Being able to show that value matters too.

Once Idlefy is running, the story doesn’t end with: Money saved. Job done.

You retain visibility into infrastructure usage and an audit trail of who started resources, when, and for how long.

And, crucially, the result of the optimization becomes visible.

Not: “I think our cloud bill is lower now.” Data.

Idlefy already has a published real-world example:

17 servers.
141 days.
1,048 rentals.
$42,983 saved.
82% cost reduction.

Now imagine that number somewhere other than our website.

Imagine it in your next performance review.

$42,983.

With a small line underneath: Initiative proposed and implemented by me.

That conversation hits differently.

And you won’t be the only one using those numbers

Because the same conversation happens at every level of the organization.

The DevOps Engineer explains value to the Head of Engineering. The Head of Engineering explains the function’s efficiency to the CTO. The CTO explains technology spend to the CEO, CFO, or owner.

And at every step, nice words become less useful. People want data.

So one engineer’s initiative can solve several problems at once.

It identifies inefficient spend. It reduces it. It gives leadership better visibility into infrastructure usage. And it makes the result measurable.

At that point, the engineer has done much more than introduce another tool.

They found the waste; brought the evidence; proposed a solution; helped implement it; and made the outcome visible to the business.

Those are the people who become expensive to lose.

Steal 15 minutes from your CTO

Actually, don’t even start with a demo.

Start with the free Idle Audit.

Look at your own data.

Nothing meaningful to optimize? Great. We’ll survive.

But if there is, now you have a reason to walk into your CTO’s office.

Not: Hey, some SaaS company wants 15 minutes of our time.

But:

I looked at our non-production infrastructure.
Here’s what happens outside working hours.
Here are the instances generating the largest idle costs.
Here’s roughly what that’s costing us.
There’s a way to automate this.
Give me 15 minutes and I’ll show you.

Now book the demo.

We don’t need to convince your CTO that Idlefy looks cool. We just need to look at the math together.

If the math doesn’t work, don’t buy it. Seriously.

But if it does, you’ve just done something far more interesting than finding another DevOps tool.

You found money the company didn’t realize it was losing.

Do something valuable. Then make sure people can see the value.

We like to believe good work speaks for itself.

Unfortunately, good work is terrible at speaking for itself.

Especially when there are two layers of management, five dashboards, and a quarterly P&L between the engineer doing the work and the person making budget decisions.

So one of the most useful habits a technical specialist can develop today is this:

Don’t just create value. Make the value visible.

For one company, that might mean cloud optimization. For another, automation. Architecture. Developer productivity. Prevented downtime. Faster time to market. Or a technical initiative that directly helps the company generate more revenue.
Idlefy is only one concrete example. The principle is much bigger.

Find it. Measure it. Do it. Then learn how to explain what changed.
Maybe that’s the new career insurance

Not certification.

Not another technology in your LinkedIn headline.

Not even closing more tickets.

Maybe it’s the habit of asking: “Where can my technical expertise change the numbers of this business?”

Because a good engineer solves technical problems.

A strong senior understands which problems are actually worth solving.

And the kind of technical specialist who becomes very expensive to lose understands one more thing:

How solving a technical problem shows up in the numbers of the business.

Nobody is truly unfireable.

But you can become very expensive to lose.

And sometimes it starts with one perfectly reasonable engineering question:

“Why the hell are we paying for this at 3 a.m.?”

Sharing My Secret for Fast, Security-First VM Deployment on AWS. Save This Post!

Tetiana Anisimova — Thu, 17 Sep 2026 14:39:58 +0000

Usually, when a company spins up a server for a developer, a DevOps engineer or admin has to manually configure the firewall, SSH access, logging, security updates, and much more. It's usually the same set of steps and tools every time. The process is fairly involved, especially when you have to repeat it regularly for multiple developers. It's easy to forget something or make a mistake, and the cost of that mistake can be high.

In this article I want to share experience I've built up over the years, and after "hundreds of hard-earned lessons."

You need to set up a development environment on a VM in AWS. What tools do you need?

Basic utilities. git, git-lfs, curl, wget, jq, vim, tmux, htop, make, unzip, ripgrep, fd, and direnv.
zsh. A convenient shell. Worth setting as the default.
Node.js 24.
Docker and Docker Compose.
Traefik. A reverse proxy that runs in Docker. It gets an HTTPS certificate from Let's Encrypt and password-protects the site. This lets a developer show off a project at an address like name.ec2.region.domain.
Kubernetes tools. kubectl, helm, and werf.
GitHub CLI (gh). For working with GitHub from the terminal.
Claude Code. An AI assistant for working with code.
Python tools. uv and uvx.
yq. Like jq, but for YAML files.
Tailscale. Private access to the machine over VPN.
NVIDIA Container Toolkit. Lets Docker use the GPU. Needed only if the machine has one.

Problems you can run into if you don't think about security

Let's look at the main ones.

AWS keys leaked. A developer installed an npm package with malware in it. The package quietly grabbed the keys off the machine. The next morning, the AWS bill shows crypto mining charges.

Countermeasure. Lock down the AWS metadata endpoint so only root can reach it, and enable IMDSv2. Issue short-lived AWS credentials that refresh every 15 minutes and live only in memory. Install Falco so it raises an alert the moment something tries to grab the keys.

The machine got hacked through an open port. Bots scan the internet around the clock. They find an unprotected server within minutes and start brute-forcing passwords.

Countermeasure. Set up an iptables firewall. Block all inbound traffic and open only SSH, HTTP, HTTPS, and Tailscale. Disable password login and root login. Install fail2ban to block an IP after 5 failed attempts. Turn on kernel network hardening settings (sysctl).

Everyone has root. Any mistake or piece of malware instantly gets full control of the machine. Anything can be deleted, and the tracks can be covered.

Countermeasure. Remove sudo rights from the developer. Run Docker rootless, so a compromised container doesn’t hand over control of the machine. Configure Falco to alert on every sudo call.

Nobody knows what happened. There are no logs. Or they lived on the machine that’s already been deleted. There’s nothing left to investigate.

Countermeasure. Ship all logs to Grafana Cloud via Grafana Alloy. The log lives separately and survives after the machine is deleted. Log every sudo attempt separately. Set up chrony for accurate timestamps in the logs.

Configuration drift. Someone tweaks something by hand “just for five minutes.” Six months later, 20 machines are configured 20 different ways.

Countermeasure. Define all settings as code and install the CINC client. Every 30 minutes it checks the machine against the reference config and puts everything back in place.

Forgotten updates. A vulnerability is found in OpenSSH or Docker. Updating everything by hand takes forever, and one machine is bound to get missed.

Countermeasure. Enable unattended-upgrades for daily automatic installation of security patches. Pin critical tools to specific versions and verify them with checksums.

An employee leaves the company. Their SSH key is still sitting on five servers. Nobody knows exactly which ones.

Countermeasure. Keep developers’ SSH keys in a single file alongside the list of machines. That way it’s immediately clear who has access to what and where. Don’t give admins permanent keys. They get a temporary key through EC2 Instance Connect that stops working after 60 seconds.

Everything depends on one person. All the security knowledge lives in one admin’s head. They leave, and the team has no idea how anything is set up.

Countermeasure. Keep the entire configuration as code (CINC). Any team member can read how a machine is configured and reproduce it.

Problems with clients and audits. A client asks how you secure your infrastructure. There’s nothing to show, and the deal stalls.

Countermeasure. Show the audit log in Grafana, ready-made alerts for suspicious events, and Falco’s reports. That’s ready-made proof the security actually works.

An easy, reliable solution

I believe I promised a quick way to do this. Well, here it is.

The Idlefy team built a free, open-source project with a ready-made, up-to-date set of solutions and tools. You can check it out here.

You don't need to worry about your data's security. Idlefy has no direct access to the server. Control happens only through a special tag and AWS access permissions.

So, what's it going to be? Reinvent the wheel, or take one that's already built?

How Our Client Saved $42,983 in 141 Days by Optimizing Idle VMs

Tetiana Anisimova — Thu, 10 Sep 2026 10:11:05 +0000

Real numbers. $42,983 saved · 17 servers · 141 days · 1,048 leases · 82% cut in compute spend

The client came to us needing to cut what they were spending on idle virtual machines in AWS. Seventeen servers and a team of engineers. They had tried building a chatbot in house, but in practice the implementation turned into chaos and never delivered the results they were expecting. Then they set up a cron job to shut everything down at 8pm. The cron lasted until the third time it took a machine down mid-release. After that the predictable reflex kicked in. The schedule was switched off "just for a week" and nobody ever came back to it.

Requirements:

Automate the VM lifecycle so that it fits into the team's routine instead of becoming a job of its own.
No loss of productivity. An engineer should not wait for access to a machine and should not have to go into the AWS console.
No resource cuts. No downsizing instances, no changing instance types, no shrinking disks. The hardware under the workloads stays as it is.
Security. Last on the list and first in importance. An external service gets access to a cloud account, and that access has to be verifiable, limited in permissions, and revocable in one click.

Idle VM management is a narrow topic, but it hides a lot of non-obvious details, and almost all of them surface in the second week of a rollout, not the first.

Step 1. Numbers first, action second

We have written separately about where to start when auditing virtual machines. Optimization without measurement turns into guesswork. Before switching anything off, you need to understand six things.

When exactly the machines sit idle.
How much money that idle time actually burns.
Which instances are the main offenders.
What automation can fix and what it cannot.
How the load is spread across providers and regions.
What it costs right now.

You do not need to pull an analyst and an engineer off their work for a week to get this. We start with the free Idle Audit. It reads 30 days of history across the infrastructure and prices every idle hour. It connects with read-only access, and nothing in the infrastructure has to change.

Step 2. Checking security

This is usually the longest stage of the conversation, and rightly so. Here is how access works.

There is no agent to install. Idlefy works through the cloud provider's API. Nothing goes onto the VMs themselves, no extra ports get opened, and we do not touch your network configuration.

Authentication without keys. By default this is OIDC federation on the AWS side (Web Identity Federation) and Workload Identity Federation on Google Cloud. No long-lived access keys are stored anywhere, because there are none. You can revoke the trust in your own console, and access ends immediately, without contacting us. A legacy mode with an encrypted key exists for older accounts, but we do not recommend it and we do not offer it to new clients.

There is almost no write access. Read access covers the whole account, otherwise the audit cannot price the fleet. Write access, meaning start, stop and reboot, works only on machines carrying the idlefy=enabled tag. On AWS that condition lives inside the IAM policy itself.

{
  "Sid": "IdlefyVMManagement",
  "Effect": "Allow",
  "Action": [
    "ec2:StartInstances",
    "ec2:StopInstances",
    "ec2:RebootInstances"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": { "ec2:ResourceTag/idlefy": "enabled" }
  }
}

This is a shortened excerpt. The recommended policy also carries a read-only block for inventory, access to metrics and pricing, and a legacy capitalized spelling of the tag. The platform shows the full JSON during setup.

Here is the key point, the one that answered 90% of the client's questions. This restriction is enforced by AWS itself, not by our good behavior. A machine without the tag is physically out of reach for our calls, and you can confirm that in your own console instead of taking our word for it.

One honest difference on Google Cloud, which we always raise up front. IAM in GCP cannot scope start and stop by label, so the boundary is held by the Idlefy application. A machine comes under management only if it carries the right label at the moment Idlefy discovers it, and any of them can be switched off from the dashboard. That is a software check on our side, not a policy your cloud enforces. If you want a boundary that GCP itself is responsible for, move the managed machines into a separate project and grant the service account a role only on that project.

We stop machines, we do not delete them. A lease expiry performs an ordinary stop, the normal power-off carried out by the provider. Terminate is never called, under any circumstances.

The root disk and attached persistent disks stay where they are, so files, packages and cloned repositories will be exactly where you left them on the next start. The instance is preserved in full, along with its ID, type and tags, and the same machine comes back up, not a new one. The only thing that can change is a non-static public IP, and that is the cloud's behavior, not ours.

What is lost is exactly what is lost on any power-off. Memory and running processes, tmux sessions included, and anything sitting on local scratch disks, meaning instance-store on AWS and local SSD on GCP. Most GPU and ML instance families carry those disks, so we flag this with engineers during onboarding and ask them to sync anything important off scratch before the lease ends. Idlefy adds no extra risk here. The semantics are exactly the same as hitting Stop instance in your provider's console.

Step 3. Trying it free on one machine

We started with a single machine on the free plan.

Here is how it works.

Machines are off by default.
An engineer takes a lease. A fixed booking for an hour, for a workday, or for up to 72 hours on the Pro plan. From Slack, from the Telegram bot, or with one click in the web dashboard. The machine comes up in about a minute.
At 20 minutes and at 5 minutes before the end a warning arrives in every connected channel.
Extending happens right there, in the same place the warning arrived, with one tap. The timer moves and work continues.
When the lease expires, Idlefy stops the machine. The shutdown is executed by the platform, but the time was always set by a person.

Pro also has the Safety System. If the lease has expired, the machine still looks busy, and nobody answered the warnings, the system grants one grace period of 30 minutes and pings you again. The scenario it was built for is a familiar one. Your Wi-Fi drops in the middle of a deploy. Activity can postpone the stop by that one window, but it can never cancel it.

This is the point where the client had that "wait, we could just do this?" moment. Not because the technology is complicated. It is extremely simple. A whole category of friction just disappears. You do not have to remember, you do not have to ask an admin, you do not have to scan the console for a forgotten machine.

Step 4. Rolling it out to the whole fleet

After that it was one day of routine. We put the idlefy=enabled tag on the relevant instances, connected the Slack workspace, and gave the team a five-minute walkthrough. That was it.

Here is what we did not have to do. We did not install agents, did not touch security groups, did not set up a VPN, did not change instance types and did not shrink disks. The fleet stayed exactly as it was. The only thing that changed was the default state.

In that time the team took 1,048 leases. Not a single ticket saying "I got shut down in the middle of my work" in all that time. The warnings at 20 and 5 minutes close that scenario completely, and the people working late simply extend from their phones.

Step 5. Voilà

Over 141 days the client saved $42,983, which is 82% of what the same fleet would have cost running around the clock. Not one instance was downsized, not one was deleted, the types and the disks stayed as they were. The only thing that changed was how many hours the machines spend powered on.

One caveat so nobody sets the wrong expectation. The saving is on compute. The disks of stopped machines keep billing at the provider's normal rate, because the data does not go anywhere. That is the price of starting your own machine in the morning instead of provisioning a new one.

The money that gets saved does not dissolve into the cloud budget. You can see it, and you can decide what to do with it. A six-figure sum per year is not a line in a FinOps report, it is three more engineers on the team. That is exactly what the client did with it, taking three people onto the payroll.

Want the same result?

There is nothing unusual about this case. If you have machines running around the clock that are needed a few hours a day, the savings will be in roughly the same range. The exact figure depends on your fleet, and you can see it in a couple of minutes without changing anything in your infrastructure.

And if you would rather not work it out yourself, book a demo. We will show what this looks like on your account, walk through the edge cases and answer any security questions. Free and with no obligation.

Run a free Idle Audit · Estimate your savings in the calculator

How to Audit Idle VMs in AWS and GCP: Where to Start

Tetiana Anisimova — Mon, 07 Sep 2026 13:42:52 +0000

Imagine a large house where the lights are on 24/7. In every room, hallway, pantry, closet and basement. When the electricity bill arrives, you start thinking about how to cut it. Swap the bulbs for more efficient ones? Keep reminding everyone to turn the lights off? The situation sounds absurd, and the fix is obvious.

What do light bulbs have in common with virtual machines?

In the world of light bulbs this problem barely exists. In cloud infrastructure it is the norm.

Why do dev VMs sit idle most of the week?

Take an ordinary dev environment. An engineer sits down to work at 9:00 and closes the laptop at 18:00. Five days a week.

That’s 45 working hours. A week has 168.

The other 123 hours the server just runs. At night, on weekends, while nobody is there. And you pay for all 168.

45 h — 27% · Engineer at work (9:00–18:00, Mon–Fri)
123 h — 73% · Nights, weekends, nobody there
168 h — 100% · Total billed

Now what if there are ten such environments? Twenty?

The solution is simpler than it seems. Development servers should sit powered off until someone actually needs them. The point is not to hunt for idle machines after the fact, when the money is already gone, but to change the default itself. The machine is off. An engineer leases it for a session, and it comes up. The session ends, and it shuts itself down.

What do AWS and Google Cloud recommend?

This isn’t some homegrown idea. Both platforms say it in their own documentation.

AWS wrote it straight into the design principles of the Cost Optimization pillar of the Well-Architected Framework. The wording is specific: development and test environments are typically used eight hours a day during the work week, and stopping them the rest of the time gives potential savings of around 75%, or 40 hours of runtime instead of 168. Not “consider the option”, but a basic principle on par with choosing the right instance type.

Google Cloud says the same thing in almost the same words. A Google Cloud blog post states outright that production usually runs around the clock, while dev and test machines are only needed during working hours, and keeping them on at night or on weekends serves no purpose. Then comes the point that makes the whole paragraph worth reading: stopping and starting large groups of machines by hand every day is tedious, and getting an entire organization to do it is next to impossible. The official Cloud Scheduler tutorial walks through exactly this: a 09:00–17:00, Monday to Friday schedule for machines labeled dev.

So what’s the takeaway?

Cloud cost optimization doesn’t scale through manual intervention. It scales through automation. That’s essentially what Google wrote: the problem isn’t that engineers don’t know about the stop button, it’s that nobody is going to press it every evening.

Is idle compute still a FinOps priority in 2026?

Yes. The State of FinOps 2026 report from the FinOps Foundation shows that workload optimization and waste reduction remain the top current priority for FinOps teams. Idle VMs fall squarely into that category.

That finding comes with a caveat worth stating honestly. Optimization really is in first place, but practitioners report diminishing returns. The report puts it this way: the big rocks of waste have already been picked up, and what’s left is a high volume of smaller opportunities that take more effort to capture. And if you add up governance, scope expansion beyond cloud, forecasting and organizational alignment, together they outweigh optimization.

What does that mean in practice? Manually hunting for idle machines is exactly that kind of small opportunity that takes effort. Automation turns it back into a big one.

This matters especially for dev and staging environments. If a team works mostly during business hours, there is little sense in paying for the same infrastructure at night, on weekends, over holidays and during vacations. The most effective optimization here may not be picking a cheaper VM, but cutting down the time it spends running at all.

What should an idle VM audit include?

As one practitioner quoted in the same report put it: “Dashboards are table stakes of yesterday — reactive. You have to move to proactive, real-time, automation.” But you can’t automate what you can’t see.

So here is what’s worth understanding about how your VMs run before you take on cloud cost optimization:

When exactly the machines sit idle. Not “roughly at night”, but hour by hour across the week.
How much money actually burns. Not how much you could theoretically save, but how much has already been spent.

Which instances are the main offenders. Usually it’s a few heavy machines, not an even layer across the whole fleet.

What automation can fix and what it can’t. Stopping a Kubernetes node that the scheduler will bring right back up saves you nothing.
How the load is spread across providers and regions. If both AWS and GCP are connected, look at them separately. Idle patterns and prices differ.
The real cost right now. Idle time isn’t a one-off finding, it’s a continuous process. It needs monitoring, not a check-in once a quarter.

You can write your own scripts to answer these six questions. Or you can get the same picture from your account’s real data in a couple of minutes with the free Idle Audit.

Originally published at idlefy.com on September 4, 2026.