Inspiration
I have experiences working with 3 different enterprise product base companies as a software developer and the biggest inspiration to build Ignition was the time it takes to start this legacy codebases and the pain of waiting for the failure messages to show up whenever any of the dependencies like redis, other microservices or the database is down. You wait for minutes till the retries are done to finally log that the service is down and is hindering your codebase to start and get deployed and guess what, if your application uses minimal logging, it becomes a nightmare to figure out what is stopping from the localhost to start. Sure, since last 1 or 2 years, with all this AI tools like chatgpt, claude, cursor - its becoming easy but you still have to go to the chat bot and say hey, this is my codebase my logs are stuck, why is my localhost throwing 500?... and then it will take again minutes to figure it out for you.
I named it Ignition as it implies the starting of a journey, here it implies starting a developer's journey to contribute to the world of tech and Ignition would be a small help me to speed up the departure!
What it does
Ignition is a Codex-built tool for developers that validates the runtime dependencies a codebase needs before starting an application or deploying it. It checks that selected configuration is present, confirms a service is reachable, understands Docker Compose container state, and—where a driver is available—performs a harmless authenticated operation such as SELECT 1 or Redis PING. It never prints secret values.
The core Ignition workflow is to select only the dependencies needed for startup, test actual reachability/authentication, and distinguish “configured” from “actually available. The important distinction is between configured and actually available. A Redis URL can exist in .env while Redis is stopped, unreachable, or rejecting credentials. Ignition lets a developer select only the dependencies relevant to the current task—such as Redis alone—then validates that real connection.
Further if a developer has added other variable optional dependency like an additional microservice or used JMS to connect another integrated apps in the .env, those can be checked only if needed and not every time when the code starts to avoid unnecessary work. The necessary dependencies while using the tool for the first time can be set under Configure Saved Dependencies, and for all the other times, that can just select the ones that they want to check to save time.
How we built it
We built Ignition as a Node.js runtime-validation engine with several interfaces: a guided CLI and batch launcher, a JSON/CI command, an MCP server, and local VS Code and IntelliJ integrations.
The core scans common configuration signals, creates a lightweight dependency manifest, scopes checks to the user’s selected dependencies, and executes independent checks in parallel with timeouts. PostgreSQL, MySQL, Oracle, SQL Server, and Redis use database/client drivers for authenticated probes. Docker Compose checks run in the Compose context for internal names such as postgres and redis.
Challenges we ran into
Large legacy repositories contain many optional integrations, test variables, CI settings, and internal constants. Treating all of them as startup requirements created noisy false failures. Moreover, docker Compose service names are valid only inside the Compose network, so a host-machine TCP check can fail even when the service is healthy so to simply put, - for codebases using containerization, for testing the tool, the docker service should be accessible from the place where codebase is deployed.
The tool is available as a plugin in VS Code and Intellij so for a developer who is aware of using both of this IDE, it would be simple to configure it.
Accomplishments that we're proud of
- A developer can save a normal startup dependency set (set under Configure Saved Dependencies which can be modified in the next runs), then run a one-time Redis-only or database-only check without changing that saved configuration.
- Ignition performs real, harmless validation queries rather than stopping at “the environment variable exists" keeping the distinction of configured and actually available.
- Ignition is available through guided CLI, CI JSON, MCP, VS Code and IntelliJ plugins.
- Secret values are never printed in reports or saved in Ignition settings.
What we learned
IDE integrations are most maintainable when they call a stable, structured core rather than reimplementing service checks so though Ignition is available as an MCP, CLI, .bat application and as VS Code and Intellij Plugin, the core that is being called is the same, initially I had thought to make API's. publish the VS Code and IntelliJ plugins.
What's next for Ignition
- Publish the VS Code and IntelliJ plugins and make them available to marketplace.
- Add deep adapters for Kafka, RabbitMQ, S3/object storage, and common API authentication schemes.
- Add migration status, version compatibility, TLS certificate expiry, and read/write permission probes.
- Add blocking pre-run hooks for IDE launch configurations and CI/CD deployment gates.
Log in or sign up for Devpost to join the conversation.