Yep. An Earthfile describes your build steps in a containerized format. Because of this sandboxing it can run identically in CI or on your local. So you just describe your build in the earthfile and call it from CI. This means you can iterate locally and it also means switching CI vendors is simple.
You can see this in action with the Elixir Phoenix framework. They have an earthfile[1] and use github actions[2] to run it for CI.
Even if you don't use Earthly, using a vendor neutral format to describe your build process can help with iteration time.
[1] https://github.com/phoenixframework/phoenix/blob/master/Eart...
[2] https://github.com/phoenixframework/phoenix/actions/runs/146...
In Show HN: Earthly v0.6phoenixframework
phoenix
Elixir2014–2026
phoenixframework / phoenix
phoenix
Peace of mind from prototype to production
39Distinct people
45Mentions
1Explicit recommenders
23.2KGitHub stars
What to know before exploring
What it is
Peace of mind from prototype to production
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
It's really awesome how Phoenix has come a really long way in a really short period of time. Chris and José (and many others) do an excellent job of carefully considering…
rubiquity used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- elixir-ecto/ecto · linked in 4 of the same discussions
- elixir-lang/elixir · linked in 3 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 8:59:20 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year45 dated mentions
Observed mentions: 2014-06-23 16:37:03 UTC to 2026-06-04 10:08:44 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 4 | 2 | 2 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Peace of mind from prototype to production.
Getting started
See the official site at https://www.phoenixframework.org/.
Install the latest version of Phoenix by following the instructions at https://phoenix.hexdocs.pm/installation.html#phoenix.
Documentation
API documentation is available at https://phoenix.hexdocs.pm.
Phoenix.js documentation is available at https://phoenix.hexdocs.pm/js.
Contributing
We appreciate any contribution to Phoenix. Check our CODE_OF_CONDUCT.md and CONTRIBUTING.md guides for more information. We usually keep a list of features and bugs in the issue tracker.
Generating a Phoenix project from unreleased versions
You can create a new project using the latest Phoenix source installer (the phx.new Mix task) with the following steps:
Remove any previously installed phx_new archives so that Mix will pick up the local source code. This can be done with mix archive.uninstall phx_new or by simply deleting the file, which is usually in ~/.mix/archives/.
Copy this repo via git clone https://github.com/phoenixframework/phoenix or by downloading it
Run the phx.new Mix task from within the installer directory, for example:
cd phoenix/installer
mix phx.new dev_app --dev
The --dev flag will configure your new project's :phoenix dep as a relative path dependency, pointing to your local Phoenix checkout:
defp deps do
[{:phoenix, path: "../..", override: true},
To create projects outside of the installer/ directory, add the latest archive to your machine by following the instructions in installer/README.md
Building from source
To build the documentation:
MIX_ENV=docs mix docs
To build Phoenix:
mix deps.get
mix compile
To build the Phoenix installer:
mix deps.get
mix compile
mix archive.build
To build Phoenix.js:
mix assets.build
Important links
#elixir on Libera IRC
elixir-lang Slack channel
Issues tracker
Phoenix Forum (questions and proposals)
Visit Phoenix's sponsor, DockYard, for expert Phoenix Consulting
Copyright and License
Copyright (c) 2014, Chris McCord.
Phoenix source code is licensed under the MIT License.
Read the full README on GitHubWhat Hacker News says
4 sourcesIt does. You just put all your actually build logic in an earthfile and call it from your github actions. A benefit of this is its easy to move CIs and you can test your build locally.
Here is an example githubaction script[1].
https://github.com/phoenixframework/phoenix/blob/master/.git...
In Show HN: Earthly – Better BuildsI see this criticism a lot but I don't think it has anything to do with macros specifically and more so to do with lack of familiarity with Elixir. I've felt the same way about Django being magic because I had trouble following the class hierarchy. It makes a lot more sense now because I'm more familiar with Python and Django. But even today I'll be looking deeper at something and ask WTF it's doing. In that respect, Elixir codebases are easier to me. The module depth seems "shallower" and I don't have to disambiguate between what behavior is caused by class inheritance or an imported function.
When I first tried to use Elixir several years ago Ecto.Schema [0] seemed complex and magical, but then I came to realize it's just converting module attributes to runtime code. There is not really that much complex macro logic going on.
>This also
Read the rest
leads to cryptic errors where you get an error in non existant lines of code.
When was the last time you used Elixir? This isn't a problem I can recall having in the last 4 years or so of using Elixir.
>following the control flow in Phoenix is like a maze because of all the macro substitutions.
Can you clarify what you mean by this? A specific case as to where this happened for you would help. Phoenix's use of macros is actually pretty light [1] except for some very low level stuff. You can even see how frequently a developer will use macros in Phoenix by searching `__using__` in the codebase [2]. It's not used as much as people think. The majority is for views and controllers and only to provide a very thin layer of support on top of your regular use of code. As an example, the "macro magic" in Phoenix.Controller is just handling some basics for giving a layout and view to Plug and handling fallback actions for exceptions. You could do the plug calls manually and I think it would be safe to not use any macros in your controller code.
Another familiarity issue with the language (and any language really) is understanding what is meaningful in a stack trace and what isn't. And the likely cause of the error in the first place. Is it syntax? Is it mistyping a variable? Is a function just used improperly? (wtf is init_p_do_apply and why does it show up in every stacktrace?) You're juggling all these different issues - learning a new paradigm, a new syntax, not knowing how to extend things. It's obviously going to be a little overwhelming and, if not strictly required, we might just pick a different language that we're more familiar with.
[0]: https://github.com/elixir-ecto/ecto/blob/master/lib/ecto/sch...
[1]: https://github.com/thechangelog/changelog.com/blob/master/li... (not mine, I just go here to show the most frequent use of macros in Phoenix)
[2]: https://github.com/phoenixframework/phoenix/search?q=__using...