Create Missing Environment Setup Validation

[Codewithspike]

There is no validation that required env variables are set at startup.

What to do:

Create env validation middleware
Check AWS credentials, session secret, GitHub OAuth, database URLs at startup
Provide clear error messages if missing
Use api docs to get details about .env files location per service.

[github-actions]

👋 Welcome! Please add relevant labels to help us categorize this issue:

Difficulty: easy | medium | hard
Type: bug | feature | documentation | enhancement
Priority: priority-critical | priority-high | priority-medium | priority-low
Status: good-first-issue | help-wanted | needs-review

Maintainers will help add appropriate labels as well!

[Hellnight2005]

Hi @atithi4dev ,

I’d like to work on this issue. My approach will be to add strict environment variable validation at startup using a schema-based solution (e.g., Zod). Each service will validate required env vars early during initialization and fail fast with clear error messages if anything is missing.

Could you please assign this issue to me?

[Codewithspike]

can u explain a little more realted to context of --

How do you plan to validate environment variables that are injected at runtime via ECS/ECR (task definitions, secrets, or parameter store), rather than local .env files?

Given this is a multi-service architecture, how will you scope and track environment validation per service without introducing tight coupling or duplication?

Since TypeScript is the core language and several services currently rely on non-null assertions (!) for env access, how do you plan to reconcile or refactor this without breaking existing startup flows?

[Hellnight2005]

Hi @Codewithspike,

To ensure I was aligned with the project's structure, I’ve already spun up the full stack locally (including the gateway and supporting services like Kafka, ClickHouse, and Mongo) to verify the current startup flow.

My approach to your points:

Runtime Injection (ECS/Secrets): I will target process.env directly. Since all injection methods resolve there at runtime, the validation remains provider-agnostic and will force a "fail-fast" exit before the app enters a broken state.

Multi-service Scoping: I’ll use service-specific schemas to prevent coupling. Common infrastructure (Kafka/DB) can be defined as shared "traits" in @veren/domain and imported where needed to avoid duplication.

Refactoring non-null assertions (!): I’ll export a validated config object instead of using process.env directly. This provides static type safety and allows for a gradual migration away from ! assertions without breaking existing flows.

I’m happy to start by implementing this in a single service, such as the api-gateway, as a proof of concept before extending it to the rest of the architecture. Let me know if this works for you!

[Codewithspike]

Sure please work on api-gateway , as for ECS we can discuss it based on different approach since most of the env being passed is through build-worker.
Please make a pr handling api-gateway fail as soon as env is missing, also keep app.ts and index.ts which are main root for the service clean , u can add the related code to either utils or middleware as u find good.

[atithi4dev]

/assign @Hellnight2005

[github-actions]

✅ Issue assigned to @Hellnight2005. Please follow the CONTRIBUTING.md guidelines.

[Hellnight2005]

Is Veren primarily intended for single-application deployments at this stage?

By single-application, I mean a monolith or a simple monorepo with one frontend and one backend deployed through a single build pipeline. Is this an intentional design choice, or are there plans to support microservice deployments in the future?

[atithi4dev]

For now we are going with single monolith deployment pipeline, but in future plans are to add multi build layer to support microservices as well as support for more than just node environment.
Hope that helps!
Any update regarding issue assigned?