Speaking for myself, I've put enough tooling around Packer to make it tolerable in my build pipeline and I haven't found a better tool that does what it does (suggestions welcome!). I would be using Vault, except it's just on the far edge of usable for me (particularly around the aws-ec2 provider) and I am repelled sufficiently by Go that I'm not driven to hack it to suit my needs until I exhaust my other alternatives, and I haven't yet.
Consul is...fine, I guess? It's not particularly useful for me, but that's because I have a Zookeeper background and am comfortable with its primitives. I'd use it if I had a need for it. OTOH, I've had extremely bad experiences with Terraform, both in terms of trying to build tooling around it and in having it hose states when resources fail to create correctly (I've mentioned previously around here that multiple clients independently invented the term "terrafucked" for the results of their Terraform state) and I don't feel like I can trust the tool with something as critical as my cloud infrastructural resources. I might bite the bullet and use it if I were working on Google Cloud or Azure, but in AWS, CloudFormation (with tooling on top) is sufficient.
A long, long time ago? It has been a while. But it also isn't what I'm looking for. Aminator is designed for pretty restrictive situations where you're deploying applications (in the form of single RPMs). And I do a lot of that in what Aminator considers a base AMI, and that's fine...but what do I use to build the base AMI? =)
Packer has a lot of user-friendliness problems (destroying build artifacts on failure, as the OP noted, being just one of them), but it does constrain the universe sufficiently that I can just run Chef and get on with my day.
If what you are after is generating AMIs for JVM, Node.js or Go apps, we at Boxfuse offer a great alternative to Packer with very fast creation of very small and secure AMIs https://boxfuse.com/blog/amis-in-30-seconds
So I spent some time studying your product, and it looks like you'd like to charge me $100/month besides for a worse experience with more constrained features than what Packer gives me. At a very fundamental level it doesn't even look like it considers the notion that not everything is an app, that high-availability, fault-tolerant services exist and need to be run, that even "immutable" servers need a consistently updated method of service discovery and credential retrieval to be effective.
If I'm wrong, please let me know how I can write, as I would using Chef and Packer, a set of directives to install and prep Zookeeper, then discover other Zookeeper nodes in my cluster at runtime, while remaining aware of nodes that are replaced due to system failure. (If the explanation exists and involves "our proprietary, closed-source agent," or "our open-source agent that talks to a proprietary backend", you don't have an answer.)
First of all thank you for evaluating our work. As I clearly stated in my post above, Boxfuse isn't intended as a general purpose replacement for Packer. If your usage falls within the usecases I highlighted it can be a very good fit though.
As for the notion of "immutable" servers, this industry term means servers that aren't updated in place, not servers without a read-write file system or read-write memory.
In the case of service discovery with client-side load balancing you can easily integrate client libs for services like Eureka or Zookeeper directly in your JVM application, or you can ship an agent (like Consul for example) and run that. You have a minimal Linux x64 system after all.
And no you don't have to pay $100/month. The licensing is based on a freemium model and your first app is free forever. And at the end of the day all you need to do is make the decision whether those monetary costs outweigh the value you get. And if it doesn't that's fine too. It simply means Boxfuse isn't the right fit for you.
You explicitly asked for suggestions for alternatives. All I did was provide one in case it may prove useful for you.
Boxfuse is not an alternative to Packer, though, except from a very great distance if one squints. It is a restricted platform play. This is why I asked how Boxfuse deploys Zookeeper, not a Zookeeper client. Which it can't do, which makes it even further not an alternative because anybody who's going to have even a moderately complex environment--which is to say "anybody who needs more than RDS"--is going to still need Packer (or a configuration management rig, Packer's just memoizing a lot of the initial stuff you'll re-run on convergence) to build out the rest of the infrastructure.
I'll be honest: I cannot envision a company that should use Boxfuse. Not one. They're better off with something like a Racker template that takes a few parameters and feeds them into Packer than your spooky-action-at-a-distance stuff.
Consul is...fine, I guess? It's not particularly useful for me, but that's because I have a Zookeeper background and am comfortable with its primitives. I'd use it if I had a need for it. OTOH, I've had extremely bad experiences with Terraform, both in terms of trying to build tooling around it and in having it hose states when resources fail to create correctly (I've mentioned previously around here that multiple clients independently invented the term "terrafucked" for the results of their Terraform state) and I don't feel like I can trust the tool with something as critical as my cloud infrastructural resources. I might bite the bullet and use it if I were working on Google Cloud or Azure, but in AWS, CloudFormation (with tooling on top) is sufficient.