You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature Idea: Task Definition as the mapping file #37
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.
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!
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!
Quick update: since we last chatted here, Envilder has shipped runtime SDKs for .NET, Python, and Node.js! 🚀
These do exactly what you described: load secrets from AWS SSM (or Azure Key Vault) directly into your app's environment at startup. No .env file needed, no intermediate steps. Perfect for recreating your ECS environment locally.
If you're working with .NET, Python, or Node.js projects that deploy to ECS, this should solve your use case natively. Would love your feedback if you give it a try!
Activity
macalbert commentedon May 21, 2025
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
.envfiles 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 commentedon May 21, 2025
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!
macalbert commentedon May 2, 2026
Hey @supergibbs! 👋
Quick update: since we last chatted here, Envilder has shipped runtime SDKs for .NET, Python, and Node.js! 🚀
These do exactly what you described: load secrets from AWS SSM (or Azure Key Vault) directly into your app's environment at startup. No
.envfile needed, no intermediate steps. Perfect for recreating your ECS environment locally.Full docs and examples at 👉 https://envilder.com/docs
If you're working with .NET, Python, or Node.js projects that deploy to ECS, this should solve your use case natively. Would love your feedback if you give it a try!
Go and Java SDKs are also in the pipeline 🛠️