Todoer
The intentionally vulnerable practice target — and how to run the full loop against it safely.
What Todoer is
Todoer is an intentionally vulnerable full-stack task management app — the official practice environment for Nimbus Vault. It is not a CTF: no flags, no labelled vulnerability boxes. It looks and behaves like a real app because it is one, with real bugs buried in it. Difficulty: intermediate → expert.
It exists so you have somewhere safe and legal to test playbooks before pointing them at a live program. A hosted instance runs at todoer.site; the source, self-hosting instructions, and disclosure policy live in the Todoer repository.
Two ways to use it
- The seeded practice target. Every workspace seeded from the Starter Library includes the Todoer platform, a Todoer Bounty program, and an intentionally unmapped
todoer.siteasset. It is the fastest way to try the loop end to end: you supply the mapping, the engine supplies the rest. - Self-host your own instance. Clone the repository and run it on a VPS with your own domain — the README covers the nginx-proxy and automatic HTTPS setup. Useful when you want a private target to rehearse against before a live rotation.
Practice the loop
Run the full cycle against a real application:
- Map — open the seeded asset and link what you observe: the stack, the features, the behaviors.
- Match — watch ranked suggestions appear as the engine correlates your library with what you mapped.
- Confirm — work the checklists to turn gaps into concrete next questions.
- Execute — run the surfaced playbooks against the target, within its rules.
- Earn — record outcomes honestly; successes yield primitives that unlock the next playbook in a chain.
Ground rules
Only test instances you own or are explicitly authorized to test. Todoer exists so that practice is unambiguous — self-host it, or use the hosted instance under its VDP. Real targets are governed by program scope and rules.