Feature Idea: Task Definition as the mapping file

[supergibbs]

Allow using the ECS Task Definition as the mapping file. Could pass file name and container name/index but could default to task_definition.json and first container for simpler convention use. Added bonus, could merge environment and secrets sections to get the full .env.

[macalbert]

Ei @supergibbs thanks a lot for the proposal, really appreciated! 🙌 ❤

I’ve been giving it quite a bit of thought, and I can definitely see how using the ECS Task Definition to generate .env files could be useful in some cases, especially for staying aligned with what’s actually deployed.

That said, I think it’s important to highlight that Envilder is (very humbly) trying to define a new standard, a clear and explicit spec that acts as the source of truth in itself, not just a reflection of existing infrastructure like ECS tasks.

I believe that one important reason why the ECS Task Definition isn’t ideal as the source of truth is that it’s very tightly coupled to AWS. It’s not agnostic and includes a lot of platform-specific configuration that may introduce noise or unnecessary complexity. This coupling makes the definition harder to maintain and reduces portability, which is something I would like to avoid with Envilder.

That said, using the ECS task definition as an optional helper or import mechanism still makes sense, especially if it helps bridge the gap for existing setups. But probably not as the main or default source of truth.

Again, thanks a lot for sharing the idea, it’s super valuable to explore these angles!

[supergibbs]

Oh I think I misunderstood. You intend to use Envilder to create a .env and include in the deploy. I was thinking this was to recreate a dev (or other) environment locally. ECS automatically pulls parameter store in as env vars, so, for those projects, this would help test locally. Maybe a future use case!