NeverIdle: burning resources to keep a cloud instance alive

What the program is for

NeverIdle is a Go program whose stated purpose is to waste resources on a schedule, and the README explains the motivation in one line, that it is for keeping a free Oracle Cloud instance alive. The reasoning is straightforward. Some providers reclaim machines that look inactive, and a machine that is only used occasionally can look inactive even when it is wanted, so a program that consumes a measurable amount of CPU, memory and network keeps the utilisation counters high and the machine alive. The author is explicit that the program was written casually, that the documentation is casual too, and that the one-click script was contributed by somebody else, so the tone of the project is a utility rather than a product. The licence is the AGPL-3.0, which is the most restrictive of the common open source licences and which matters more here than it would for a normal library, because the tool is designed to be run as a service on a machine you do not own.

The flags, and what each one actually does

The command line is short and the example in the README shows three flags at once:

./NeverIdle -cp 0.15 -m 2 -n 4h

The -c flag turns on periodic CPU waste with an interval after it, and the interval uses a duration format, so a burn every twelve hours, twenty three minutes and thirty four seconds is written as such a duration. The -cp flag is the coarse version, a fraction between zero and one that gives the maximum share of the processor to waste, and the README is careful to say it must not be combined with -c. The waste rate in this mode follows the machine's current usage rather than sitting at a fixed figure, so it backs off when the host is busy. The -m flag takes a number of gibibytes of memory, which the process allocates at startup and then holds without releasing until it is killed. The -n flag is the network equivalent of -c, and it works by running the Ookla speed test on the interval, which also prints the result. The -t flag sets how many connections that speed test uses, ten by default, and the -p flag sets the process priority, with the platform default being the lowest priority so the tool yields to everything else on the machine.

Installing it, including the container route

There are three ways in, and the README recommends the middle one. You can paste the one-click command, which downloads a script and runs it, and the project is candid that this will not cover every situation, for instance a machine without two gibibytes of memory or with no need to waste memory at all, and it recommends installing it yourself instead. You can download a release binary, in which case the note to read is to pick the right architecture, since the builds exist for amd64 and for arm64, and the repository also has build scripts for both Unix-like systems and Windows. Or you can build the container, which is the tidiest option on a server, since the Dockerfile is fetched first and then built, with an architecture argument for an x86 machine:

docker build --build-arg ARCH=amd64 -t neveridle:latest .

and run it detached with the same flags you would pass to the binary:

docker run -d --name neveridle neveridle:latest -c 1h -m 2 -n 4h

How the machine is measured and burned

The dependency list explains the implementation. The process metrics come from a library that reads the operating system counters, the speed test comes from a Go port of the Ookla client, and the process priority is set through a small package that handles the platform differences between the Unix style nice values and the Windows equivalent, which is why the README points at the Windows documentation for that flag. The tree is split in a way that mirrors the design, with a main entry point, a controller package that decides when to waste what, and a waste package that does it, alongside the build scripts and a dependency update configuration. The tool also runs the configured activities once immediately at startup so that you can see the effect without waiting for the first interval, which is a small usability decision that tells you the author has actually run this on a server.

What the program does not promise

The name and the purpose invite a misunderstanding, and it is worth being blunt about it. The program does not stop a provider from reclaiming an instance, because reclamation rules are provider specific and are not a function of a utilisation counter that a user can write to. What it does is raise the counters, and whether that is enough depends entirely on how the provider decides. The same applies to the cost side, which the README does not dwell on but which is real: the CPU is electricity, the memory is memory your workload could have used, and the network option runs speed tests that move a meaningful amount of data through a connection that is often metered. The one-click install path deserves the same scepticism, since running a script fetched over the network as root on a machine you care about is a large risk for a small convenience, and the project itself says to install it yourself if the defaults do not fit.

Licence, cadence and the shape of the project

The AGPL-3.0 is the detail with the widest consequences, and it is worth understanding before you run this anywhere. The AGPL is the licence whose copyleft reaches network use, so if you modify the program and let others interact with it over a network, you are expected to offer them the modified source. For a tool that exists precisely to sit on a server, that is the right licence for the author to have chosen, and it is also a condition you need to think about if you patch it. The release history is a snapshot of an occasional project, with 0.2.2 and 0.2.3 in March 2023 and 0.2.4 in September 2026, and the last push on 2026-10-10, so the gaps between releases are long while the dependency updates are automated. The repository is small, the README exists in Chinese, English and Spanish, and which makes it a comfortable project to read in an afternoon and to fork if you need a different wasting pattern.

Editorial conclusion

NeverIdle fits a builder with a free tier instance that is reclaimed for inactivity and who would rather keep the machine for experiments than lose it. It does not fit a production host, where the same work should be done by the workload itself, and it does not fit anyone who is uneasy about running a remote script as root. Before using it, read the flags rather than the marketing, because the memory option holds real memory for the life of the process and the network option runs speed tests that transfer real data, and check the AGPL terms, since the licence is the one with the strictest obligations in this repository family.

Frequently asked questions

Official sources

1. Issues
2. layou233/NeverIdle on GitHub
3. License: AGPL-3.0
4. README
5. Releases