Jewel container image now available on GHCR

Hi everyone,

Following up on the Ansible Jewel project announcement and the AWX modernization: Ansible Jewel post, one of the early pieces of feedback we heard was that building Jewel from source added friction for anyone wanting to try it out. Today we’re taking a step to address that.

A pre-built Jewel container image is now published to the GitHub Container Registry on every push to the devel branch:

docker pull ghcr.io/ansible/jewel:latest

What you get

  • Multi-architecturelinux/amd64 and linux/arm64

  • API server only — the image ships the Jewel API and proxy layer without the platform UI, keeping it lightweight and focused on what the community needs for development and testing

  • Automated — a new image is built and pushed on every merge to devel, so latest always reflects the current state of the branch

Important: this tracks devel, not a release

There are currently no versioned releases or stable tags for Jewel. The latest tag always points to the most recent devel build. Per-commit SHA tags (sha-<short> and sha-<full>) are available if you need to pin to a specific build, but these are snapshots of development, not releases.

Getting started

Pull the image:

docker pull ghcr.io/ansible/jewel:latest

Jewel requires PostgreSQL, Redis, and configuration to run, so a standalone docker run won’t work out of the box. To get a full working environment, clone the repo and use the development setup:

git clone https://github.com/ansible/jewel.git
cd jewel
make docker-compose

See the repo README for full details.

A note on the platform UI

The published image does not include the platform UI. The UI is maintained separately and is not currently available as a public image, so community builds are API-only for now.

What’s next

We’re interested in making the contributor experience better over time. Some things we’re thinking about:

  • Documentation improvements — better getting-started guides for running Jewel with other services

  • Release tagging — establishing a versioning and release cadence as the project matures

  • UI availability — exploring options for making the full stack accessible to the community

We’d like your feedback

We’re interested in all feedback, but especially:

  • How are you using (or planning to use) Jewel? Understanding your use cases helps us prioritize.

  • What’s still missing to get started? If you’ve tried running Jewel and hit a wall, we want to know about it.

  • Ideas on what a release cadence could look like — what would be most useful for your workflow?

Feel free to reply here or open an issue on the repo.

Links

5 Likes

So many things in relation to this post. That again are not a step in the right direction. Oh and before you say it’s a required step for releases. I say poppy-cock.

why? please follow the chain yourself, starts here → AWX modernization: Moving forward - #39 by jon-nfc

If red hat wants open source community developers to contribute. red hat can make the product usable for open source community members who are not developers. That means nothing less than releases, like any other software product. That includes everything to make it work. PERIOD.

Yeah lets raise an issue. Just so it can never be triaged, let alone worked on. Here’s one for ya [Feature]: Official builds and documentation · Issue #76 · ansible/jewel · GitHub. want more examples go to any ansible repo and look for yourself.

5 Likes

I do not work for Red Hat, and from that side I can understand people’s frustration at not having AWX releases anymore. Having a validated Ansible web platform that works for community or personal (or other) use was a great thing to have, and it was available for a long time. I can further understand this frustration if you contributed your own code / time / bug fixes, etc. to the project.

I also think we need to face a bit of a reality that the same company (CIQ) that takes RHEL sources and uses them to create Rocky Linux is also taking AWX sources and using them to build their own proprietary (!!) “AAP-like” web service.

From my side, it is just not in Red Hat’s own interests to provide a validated platform for a competitor to build from and create a similar service that the competitor can then sell at a cheaper price. That company isn’t paying for most of AWX’s development - why should they benefit so easily?

So, yes, we can whine (rightly in many ways!) about missing the validated platform, but this also seem to me like part of the blame here should be directed at groups like CIQ that take something for free that they didn’t build and try to make money off of it. Yes, I understand that’s how open source works, but why should Red Hat go out of their way to help them?

It is just unfortunate that community members are caught in the middle. But that’s a bit of the way the cookie is crumbling in 2026.

Cheers to all. I’m not trying to start a flame war.

That’s how open source works.

Whine??? All you’ve done is defend these deplorables. Why would you rationally support this???

None of my posts or others of a similar nature are whining. In fact they are calling out the these companies, red hat in this case for calling themselves open source companies or having open source software and not having anything more code. Not only that these companies want open source community developers to help them with something a majority of the open source community cant even use.

using an open source licence then crying that someone is using the product in accordance with the licence is beyond a joke. laughable really. yes taking person a’s code and reselling it is in accordance with the licence.

All I have to say to those sooks and people who support said sooks is, wa