# NostalgiaForInfinity: a Freqtrade strategy with an updater bolted on

> NostalgiaForInfinity is a Python trading strategy for the Freqtrade bot, shipped with a Docker sidecar that keeps the strategy, blacklist and pairlist current. It is opinionated about timeframe, pair selection and exit behaviour, and it assumes you already run Freqtrade.

**iterativv/NostalgiaForInfinity** — Trading strategy for the Freqtrade crypto bot

- Repository: https://github.com/iterativv/NostalgiaForInfinity
- Stars: 3,444 · Forks: 759
- Language: Python
- License: GPL-3.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/iterativv-nostalgiaforinfinity

## What NostalgiaForInfinity actually is, and who it is for

NostalgiaForInfinity is not a bot. It is a strategy file that plugs into Freqtrade, the open source crypto trading bot. The repository's own description is a single line: "Trading strategy for the Freqtrade crypto bot." Everything else in the project exists to serve that file: the configs directory, the Docker Compose stack, the tools directory, and the documentation site at iterativv.github.io/NostalgiaForInfinity.

The intended user already has Freqtrade installed and running against an exchange. If you have never configured an exchange API key, a pairlist or a dry-run wallet, this project adds nothing you can use on its own. The README assumes that groundwork and moves straight to tuning: 6 to 12 open trades, unlimited stake, a pairlist of 40 to 80 pairs, and a preference for stablecoin pairs over BTC or ETH pairs.

The repository ships several strategy variants at the top level: NostalgiaForInfinityX.py through NostalgiaForInfinityX8.py, plus a legacy directory. The docker-compose.yml defaults to NostalgiaForInfinityX7 via the FREQTRADE__STRATEGY variable, which tells you which variant the maintainers treat as the current default. Choosing among X2 through X8 is left to you; the README does not rank them.

The project is Python, requires Python 3.12 or newer according to pyproject.toml, and is licensed GPL-3.0. The last push to the main branch was on 2026-09-23, and the most recent tagged release listed is v17.5.40 from 2026-09-06. That cadence matters more than any single feature, because the strategy file changes often.

## How the strategy and the updater fit together

The strategy itself is a Python class that Freqtrade loads at startup. You point Freqtrade at it with the --strategy-path flag, and the container mounts the chosen file directly into /freqtrade. In docker-compose.yml the mount is written as ./${FREQTRADE__STRATEGY:-NostalgiaForInfinityX7}.py:/freqtrade/${FREQTRADE__STRATEGY:-NostalgiaForInfinityX7}.py. Because it is a bind mount rather than a copy baked into an image, replacing the file on the host changes what the container runs after a restart.

The second moving part is the nfi-updater sidecar. The README describes it as checking the strategy file, blacklist and pairlist against the latest version on GitHub on a configurable schedule, defaulting to daily at 10:00 in your timezone. It also watches the blacklist file through an HTTP ETag every 60 seconds and applies critical updates immediately. The container restarts freqtrade only when a file actually changed, which avoids interrupting open trades for a no-op check.

For people not using Docker Compose, the repository includes tools/checkupdates.sh. The README says it downloads either the latest release or the newest commit on main, extracts the archive, replaces the strategy files and all blacklist JSON files, then cleans up. It can optionally restart a Docker container and send Telegram notifications. The two modes are named releases and commits.

That division is the honest architecture of the project: a strategy file that is replaced wholesale, and an update mechanism whose entire job is to replace it safely. There is no plugin API, no signal library and no configuration surface beyond the Freqtrade config plus the updater's environment variables.

## Installing NostalgiaForInfinity with Docker Compose

The README's Docker path is short. The nfi-updater service is already defined in docker-compose.yml, so bringing the stack up starts both freqtrade and the updater. Run this from the repository root:

```bash
docker compose up -d --build
```

You should see two containers: the freqtrade container, named from FREQTRADE__BOT_NAME, FREQTRADE__EXCHANGE__NAME, FREQTRADE__TRADING_MODE and FREQTRADE__STRATEGY, and the nfi-updater sidecar. The freqtrade container exposes port 8080 by default through FREQTRADE__API_SERVER__LISTEN_PORT and has a healthcheck that curls http://localhost:8080.

Before starting, create a .env file next to docker-compose.yml. The README lists three settings for the updater:

```env
TZ=Europe/London
NFI_UPDATE_CRON=0 10 * * *
COMPOSE_PROJECT_NAME=nostalgiaforinfinity
```

TZ sets the timezone for the cron schedule. NFI_UPDATE_CRON uses cron syntax and defaults to daily at 10:00. COMPOSE_PROJECT_NAME must match what docker compose ls reports, and the README notes that Docker uses the lowercase folder name by default. Getting that value wrong is the most likely reason the updater restarts the wrong container or none at all.

To confirm the updater is working, follow its logs:

```bash
docker compose logs -f nfi-updater
```

What you should see is the scheduled check, and then either a no-change message or a restart of the freqtrade container. The healthcheck on freqtrade has an interval of 1m30s, a timeout of 10s, three retries and a start period of 40s, so a freshly restarted container takes a little under a minute to report healthy.

## The config keys you are not allowed to change

The README is unusually blunt here, and it is the part most likely to be ignored. It states that you should not override any variables in your config.json, especially the timeframe, which must be 5m. It then lists three keys with their required values: use_exit_signal must be true or unset, exit_profit_only must be false or unset, and ignore_roi_if_entry_signal must be true or unset.

These are not preferences. They are preconditions. A strategy that emits exit signals expects those signals to be honoured, so use_exit_signal set to false disables the exit logic the strategy is built around. ignore_roi_if_entry_signal set to false lets the return-on-investment table close positions that the strategy would have held. If you have an existing config.json tuned for a different strategy, copying it over and changing only the strategy name is the failure mode the README is warning about.

The pairlist guidance is softer but still specific: 40 to 80 pairs, a volume pairlist works well, stablecoin pairs are preferred over BTC or ETH pairs, and leveraged tokens such as *BULL, *BEAR, *UP and *DOWN should be blacklisted. That last point is a risk control, not a style choice. Leveraged tokens decay and behave differently from the underlying asset, and the strategy's exit logic was not written for them.

The README also recommends between 6 and 12 open trades with unlimited stake. Read that as a statement about how the strategy was evaluated rather than a guarantee. Running it with two open trades or a capped stake changes the exposure profile the author had in mind.

## Where NostalgiaForInfinity is the wrong tool

The clearest limitation is the dependency. NostalgiaForInfinity is a Freqtrade strategy, so every failure mode of Freqtrade becomes yours: exchange API changes, rate limits, database issues, and the operational work of keeping a long-running container alive. If you wanted a self-contained bot, this is not it.

The second limitation is documentation scope. The README points to an online documentation site and to commit comments for backtesting results. It does not describe the entry and exit logic, the indicator set, or the risk model in the README itself. The pyproject.toml declares a single dependency, freqtrade, with no pinned version, so the strategy is expected to track whatever the stable Freqtrade image provides. That is convenient and also means a Freqtrade release can change behaviour underneath you.

The third is the update model. Replacing the strategy file wholesale is simple, but it means you cannot easily carry local modifications forward. The automatic updater is designed to overwrite the strategy, blacklist and pairlist files. If you edited the strategy to add a filter, the next update cycle removes it. The README does not document rollback, so there is no described way to return to a previous strategy version through the updater. The tools/checkupdates.sh script offers a releases mode, which pulls official GitHub releases rather than main branch commits, and that is the closest thing to a stability control the material describes.

Finally, the README's own framing is a recommendation, not a performance claim. It says backtesting results are in the comments of individual commits. Anyone treating the strategy as a proven money-maker is reading past what the project actually asserts.

## Alternatives and how they differ in approach

The most direct alternative is writing your own Freqtrade strategy. Freqtrade provides the strategy interface, backtesting, hyperopt and dry-run trading; NostalgiaForInfinity is one implementation of that interface. Writing your own means you understand every entry and exit condition, and you can pin it to a Freqtrade version you have tested. It also means you own the maintenance, including the blacklist and pairlist upkeep that the nfi-updater sidecar handles automatically here.

A different category of alternative is a standalone bot that does not depend on Freqtrade at all. Those projects bundle their own exchange connectors, order management and configuration, so installing one gets you a running system rather than a strategy file. The trade-off is the opposite of NostalgiaForInfinity's: less integration work up front, and no ability to reuse Freqtrade's backtesting and dry-run tooling.

Within the Freqtrade ecosystem, the meaningful choice is between using a maintained community strategy like this one and running a minimal strategy of your own. NostalgiaForInfinity's advantage is that someone else is iterating on the signals and the blacklist; its cost is that the file changes on someone else's schedule, and the updater is built to enforce that. If you want a strategy you can freeze, the project works against you.

## Maintenance, upgrades and licence

The upgrade story is the project's strongest feature and its main operational cost. The nfi-updater sidecar checks on a cron schedule defined by NFI_UPDATE_CRON, watches the blacklist via HTTP ETag every 60 seconds, and restarts freqtrade only when a file changed. For non-Docker users, tools/checkupdates.sh does the same job from cron, with a line like 0 * * * * /path/to/your/script/checkupdates.sh running it hourly. The script supports releases mode for stable tagged versions and commits mode for the tip of main.

Choosing between those modes is the real maintenance decision. Releases mode tracks tags such as v17.5.40 and v17.4.562, which are dated and identifiable. Commits mode tracks main, which the last push shows is updated frequently. For a live account, the release track gives you something to point at when behaviour changes.

The cost side is that you are running two containers and a bind mount. The strategy file on the host is the source of truth, and the updater rewrites it. Any local edit is temporary. There is no documented staging or rollback path, so the practical safeguard is to keep your own copy of a known-good strategy file outside the repository before an update lands.

On licensing: the repository is GPL-3.0. That is a copyleft licence, and it applies to the strategy code you are running and potentially to modified versions you distribute. This is a description of the licence identifier, not legal advice. If you plan to redistribute a modified strategy or embed it in a product, read the licence text in the LICENSE file and get proper advice.

## Conclusion

Adopt it if you already run Freqtrade, want a maintained strategy file rather than writing signals yourself, and can accept the fixed constraints: a 5m timeframe, use_exit_signal true, ignore_roi_if_entry_signal true, no leveraged tokens, and 6 to 12 open trades. Do not adopt it if you want a standalone bot, a documented risk model, or a strategy you can tune without re-reading every release. Before going live, verify that your config.json does not override the timeframe or the three exit-related keys, and run the nfi-updater service once with docker compose logs -f nfi-updater to confirm it can reach GitHub and restart the freqtrade container.

## FAQ

### Do crypto bots make money?

The README makes no profit claim and points readers to the comments on individual commits for backtesting results. Backtesting results are not the same as live trading outcomes, and the project's own guidance is framed as recommendations for configuration rather than performance guarantees.

### What is NostalgiaForInfinity in Freqtrade?

It is a trading strategy for the Freqtrade crypto bot, written in Python and distributed under GPL-3.0. The repository also ships a Docker Compose stack and an nfi-updater sidecar that keeps the strategy, blacklist and pairlist files current.

### How do I install NostalgiaForInfinity?

The README's Docker path is to run docker compose up -d --build from the repository root, which starts both the freqtrade container and the nfi-updater sidecar. You configure the updater through TZ, NFI_UPDATE_CRON and COMPOSE_PROJECT_NAME in a .env file.

### What timeframe and config settings does NostalgiaForInfinity require?

The README states the timeframe must be 5m and that you should not override variables in config.json. It lists three keys: use_exit_signal must be true or unset, exit_profit_only must be false or unset, and ignore_roi_if_entry_signal must be true or unset.

### How does the NostalgiaForInfinity updater work?

The nfi-updater sidecar checks the strategy, blacklist and pairlist against GitHub on a cron schedule, defaulting to daily at 10:00 in your timezone, and watches the blacklist via HTTP ETag every 60 seconds. It restarts the freqtrade container only when a file actually changed. Non-Docker users can run tools/checkupdates.sh from cron instead.

## Sources

- [Issues](https://github.com/iterativv/NostalgiaForInfinity/issues)
- [iterativv/NostalgiaForInfinity on GitHub](https://github.com/iterativv/NostalgiaForInfinity)
- [License: GPL-3.0](https://github.com/iterativv/NostalgiaForInfinity/blob/main/LICENSE)
- [README](https://github.com/iterativv/NostalgiaForInfinity/blob/main/README.md)
- [Releases](https://github.com/iterativv/NostalgiaForInfinity/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/iterativv-nostalgiaforinfinity