Environment Setup
Understand how Kerno builds and manages your local test environment, from the initial plan to keeping it in sync as your code evolves.
Last updated
Understand how Kerno builds and manages your local test environment, from the initial plan to keeping it in sync as your code evolves.
Three components run in your test environment.
Your application (SUT). Kerno generates a Dockerfile and runs your app in a container, configured with the environment variables and startup sequence it detects from your codebase.
Real dependencies. Postgres, MySQL, MongoDB, Redis, Kafka, RabbitMQ, and similar services run as real Docker containers with sensible defaults. See Supported Technologies for the full list.
Sandbox. External services your app calls (payment providers, email services, etc.) that cannot run locally are replaced with synthetic routes. The sandbox is also where test execution happens. All validations run here.
Your environment includes the specific services Kerno detects in your codebase.
Before building anything, Kerno analyzes your codebase and produces a plan. The plan covers the application's build and runtime configuration, every dependency the app needs, secrets with placeholder values for local dev, and any questions Kerno needs answered before it can proceed.
You or your agent review the plan, leave feedback, and Kerno regenerates it with your suggestions. Once you have no more feedback, Kerno starts building the environment.
You can also edit the plan directly at any time to add a missing service, change a port, or add context Kerno could not infer.
Do not edit the generated Compose files by hand. Kerno overwrites them on every regeneration.
Once the plan is approved, Kerno generates the Dockerfile and Compose files, builds the images, and starts the containers.
Build time depends on your stack. A simple project takes around five minutes. A complex one can take up to thirty minutes. This only happens the first time, subsequent runs start the environment instantly.
If something fails during the build (a service does not start, a port conflicts, a dependency is missing), Kerno surfaces what failed and asks you or your agent for help.
As your project evolves, Kerno keeps the environment current. When you change build files, Kerno re-analyzes your stack and updates the plan if needed. Review the updated plan and regenerate the Compose files to apply changes and rebuild.
Do not edit the generated Compose files by hand. Kerno overwrites them on every regeneration.
Last updated