Nomad pack vs levant


I am new to nomad and exploring the possibility of using nomad templates to create my jobs. So far I have seen levant and nomad pack which looks like they overlap. Levante seems currently in production and nomad pack is under development.

Which one should I use?

thank you

1 Like


If its of any help there is another thread which asks about the future of these two choices, the short answer seems to be that Nomad pack / Nomad native cli will most likely become the preferred choice in the future: Future of Nomad pack and Levant - #6 by jrasell though it does also specify that the future is never certain so I don’t think there is a concrete answer for this right now at least that I know of :smiley:

Personally I am using Levant for all of my job file templating, however this is due to a combination of me building all my current deployment pipelines before Nomad pack was even released in tech preview and the lack of clarity on to what will be happening in the future. I’ve not run into any of the known issues with levant not supporting 1.3+ functionality listed here: Support latest Nomad 1.3.+ job descriptor · Issue #457 · hashicorp/levant · GitHub as I’m not using the built in Nomad service registry but your mileage may vary!

I’m looking forward to when the Nomad team will fully clarify whats going to upcomming as I share the same sentiments as @rwojsznis in their response Future of Nomad pack and Levant - #7 by rwojsznis mostly so I know when its a good time to rewrite all of my CI pipelines again :smiley:

The answer is mostly likely Nomad pack and Nomad native CLI but its not certain right now as far as I know :slight_smile:
Hopefully someone else can also weigh in on this!

Hey @CarbonCollins,

Thanks for reaching out and apologies for the confusion around this. We have had to focus on other priorities over the last couple releases, and haven’t given Pack the attention necessary to get it out of Tech Preview yet. This was a difficult tradeoff to make, but hopefully some of the 1.4 features and upcoming 1.4.X features/fixes will make up for it.

On the bright side, now that work on 1.5 has started, we’re ramping Pack work up again. We haven’t 100% locked in the work that we want to do, but we’ll have multiple engineers who are focusing primarily on Pack over the next few months.

We have some quality of life improvements that we’re looking at (auto-formatting, var file generation), some new features (non-job file rendering), and some breaking changes to the spec (enabling a better deps story & handling nested deps). Once we’ve finalized our plan, I’ll make sure to follow up here and point you to a public milestone on GH that you can look at.

Regarding Levant, we do plan to support 1.3+ features in Levant in the meantime. We plan to upgrade the Nomad API dependency in Levant to 1.4 soon - I believe this week. Apologies for the delay on this. If you are happy using Levant now, I would wait for this bump then continue using Levant until Pack hits “beta”. At that time the Pack spec should be finalized and it should be safe to convert to the new tool without adding any re-write tech debt. We’ll also aim to have a “Converting from Levant” guide around this time. For what its worth, that process should hopefully be pretty easy, as Pack is based on Levant in a lot of ways. This should be around the time 1.5 comes out, which will likely be early next year.

Let me know if you have any questions. Again, apologies (to everybody) for the confusion on this.

  • Mike, Nomad PM

As a user who has already tested Nomad and intends to one day implement it instead of Docker Swarm and does not want the complexity of Kubernates, I feel that Nomad should focus more on a single pattern for easier implementation and use, it would even be interesting to work with Docker Compose which is a very used pattern in Docker and Docker Swarm, when I started my tests with Nomad in 2021/2022 it was one of the difficulties I faced, if it was 100% compatible with Docker Compose as Podman for example tries to be, it would be possible to use it easily without much friction between one technology and another.

On the Kubernates side, there is Heml and many other projects, which also suffer from the lack of a definitive standard, but Helm tends to always be the base even though it is not as trivial to use as Docker Compose.