It's great to see this publicly launch! Congrats to the team on making a great product. The Earthfile + Earthly CI approach is so much better than GHA or CircleCI. I feel like the only piece missing is distributed builds. Maybe one day?
And the pricing scheme is awesome, especially for smaller teams.
I've been a very happy user of Earthly and this is one of the final pieces of the puzzle that I've been waiting on[1]. I've found Earthly to be the perfect balance between declarative, repeatable, flexible yet easily understandable.
While I've been fortunate to have early access to Earthly CI, the cool thing is that the Earthly primitives it uses are available for everyone to see in the latest launched version [2]. The only puzzle piece missing is distributing the compute amongst different machines but that appears to be on the team's mind.
And the zero-margin compute pricing is a breath of fresh air.
I came here to echo the pricing sentiment. I just encountered this problem and documented my company's architecture using Whimsical. I felt it was lacking.
We're a <10 person start-up. $40/mo seems too much relative to how often we'd use the tool. I would use this tool if there was a cheaper option ($10/mo/editor) for a team of our size.
As someone in the ecosystem, I've found a noticeable uptick in job postings the past few years. I haven't applied for such jobs so I can't personally attest to it.
After gaining some recent experience in Go, I'd still choose Elixir for any web project. Phoenix/Ecto/Absinthe/LiveView are all extremely productive libraries for web projects. Tooling/infrastructure work may be another discussion.
I think there is room for a framework similar to Phoenix LiveView but also allows compiling certain interactivity to the client. Next.js and Remix are kind-of fulfilling this but they have downsides.
In the BEAM ecosystem, I think there is room for [Gleam](https://gleam.run) to be used to compile to both Javascript and the BEAM.
I agree that there's room for a language that runs on the BEAM and also compiles to JS. Gleam looks great, and it's one of the up and coming languages that I'm rooting for. In addition to having a Javascript compile target, it's statically typed which is a prerequisite for me when it comes to productivity and correctness.
There was actually a developer working on a subset of Elixir that compiles to JS called Elixirscript[1], but development seems to have stalled. Another functional statically typed compile-to-js language which targets the BEAM vm is Purescript through the Purerl project [2].
If you're going to compile to JS though, there's an argument to be made that you might not want to target the BEAM at all. You could potentially run your entire backend on something like Cloudflare Workers, which has over 200 points of presence around the world, so latency is about as low as possible. The other CDNs have their own competing worker runtimes as well (e.g. Cloudfront functions, Netlify functions, etc.). These edge worker runtimes also have the benefit of not charging for each individual region in which you operate. You can also run any language which compiles to WASM like Rust, Assemblyscript, or Grain [3] on these edge runtimes. The only missing piece for me is a distributed database, but it looks like Cloudflare at least is working on that [4].
I recently converted my company's build process to Earthly. I find its syntax to be much easier to grok than CUE. They've also extended/added Docker commands that shore up some of the pain points of working with Dockerfiles.
>Dagger has a wider scope: build, test, deployment, any part of a CI/CD pipeline really
I don't see any reason this can't go into an Earthfile. We have all of these parts in our Earthfiles.
The one common pain point that both Dagger and Earthly haven't solved for me is unifying the machine parallelization with the DAG parallelization. According to this comment[1], it seems like Dagger doesn't have that goal.
For example, we only run our +deploy target if +build, +test and +lint pass. We parallelize each of those targets across workers in Github Actions. I don't know what the solution is to this problem but I know this was annoying to have to handle with Github Action's workflow syntax and horrible to debug locally.
I've met the Doppler founders and greatly respect them (even played some poker with them!). Doppler has great design and UX.
That said, I'd say the key difference is that EnvKey places much more emphasis on security and privacy. Doppler is cloud-hosted and doesn't use end-to-end encryption, so it requires that you trust them to keep your data safe and not make any mistakes in their data security, network security, who they hire, what sub-processors they trust, etc. In my (very biased) opinion, that is not sufficient protection for the most sensitive data.
Doppler also uses a web interface, which is great for convenience and UX, but leaves you vulnerable to compromised browser plugins, XSS, etc. I don't believe browsers are sufficiently secure currently for secrets management (if this changes, we'll add a web interface to EnvKey ASAP!).
There are real costs in terms of UX to end-to-end encryption. EnvKey tries to be as user-friendly as possible, but doesn't compromise on security or privacy. Doppler's design, as I understand it, leans more toward the other side of this tradeoff.
On Terraform--yes, it's easy to use EnvKey with Terraform. The general pattern for integrating EnvKey with any tool or platform is to set your ENVKEYs as secrets in whatever way the platform handles them, then expose each ENVKEY as an environment variable to your VMs, containers, or whatever else you're running. We'll write up a Terraform-specific guide soon to make it as easy as possible.
Co-founder/CTO of Doppler here. I'd agree that Doppler currently focuses very heavily on UX. We aim to fit into developer workflows, regardless of where devs run their code. This includes local development (macOS/Windows/Linux), CI/CD, Kubernetes, Vercel, and just about anywhere else. We've found that security tools that are difficult to use end up being worked around by developers, which ultimately decreases an org's security posture (see HashiCorp Vault). This does come with some tradeoffs- specifically that you must trust Doppler with your secrets, given our tokenization model[0].
We do recognize that the current security tradeoffs of Doppler aren't going to satisfy everyone. For Enterprises, we offer Enterprise Key Management (EKM), which allows orgs to encrypt their secrets using a cloud KMS. Of course, this still doesn't satisfy every concern. And so, for customers requiring additional security guarantees, stay tuned!
I wonder why is it difficult to add an extra password on top of the access key.
What I mean is you can have another password or hash (separate to normal auth pass) which is only used to encrypt at browser and decrypt at the time of usage(through env load packages or your custom doppler command. This extra password is never sent or stored at doppler server.
> I don't believe browsers are sufficiently secure currently for secrets management
This is a super rare view, but one I truly appreciate. The risk of compromised browser plugins especially is vastly understated and underappreciated by... way too many "security" "experts".
I don’t believe just about any platform we have now is really sufficiently secure for secrets management. Just as a compromised browser plugin can do a lot of damage, so too can a compromised desktop application (including its dependencies). The industry as a whole is not in a great place when it comes to protecting the integrity of our machines, especially developer workstations.
(And yes I know you probably know this better than most as a Sandstorm dev :)
This was wonderfully written. As a Nix beginner, I found it super helpful and wish there was more documentation that explained the major aspects of Nix this clearly.
Author of the post here. Thank you. I've been working on my style for teaching NixOS concepts for a long time. If I ever get around to writing a book on Nix/NixOS it's going to use either this style or a refined view on this style.
And the pricing scheme is awesome, especially for smaller teams.