# AWX modernization: Ansible UI

**URL:** <https://forum.ansible.com/t/awx-modernization-ansible-ui/45757>\
**Category:** Project Discussions\
**Tags:** ansible-ui, community, awx-modernization, awx\
**Created:** [April 30, 2026, 5:37pm UTC](https://forum.ansible.com/t/awx-modernization-ansible-ui/45757 "2026-04-30T17:37:03Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![thedoubl3j](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/thedoubl3j/32/103_2.png) [@thedoubl3j](https://forum.ansible.com/u/thedoubl3j)\
**Post date:** [April 30, 2026, 5:37pm UTC](https://forum.ansible.com/t/awx-modernization-ansible-ui/45757/1 "2026-04-30T17:37:03Z")

</div>

Hey Friends, Jake from the AWX/Controller team here,

We’ve got another update on the AWX modernization that we’d like to share with the Ansible community. As always, let’s start by revisiting some of the goals that we outlined when we set out to refactor AWX into a pluggable, service-based architecture:

- Simplify the codebase so it is easier to implement changes, add new features, and make contributions.
- Reuse code more efficiently across projects.
- Enable participation in a way that allows the community to shape the project.

## Bringing users into the picture

In our [last post](https://forum.ansible.com/t/awx-modernization-moving-forward/45134), we announced the next phase of the AWX modernization effort would be focused on providing developer resources. As part of that work we’ve added [AWX OpenAPI](https://forum.ansible.com/t/awx-modernization-exploring-the-openapi-specification-in-awx-community-documentation/45198) documentation and announced the [AWX TUI](https://forum.ansible.com/t/announcing-the-awx-tui/45591). We’re continuing to work on improving the developer experience and there will be more announcements about what we’re doing soon.

Developers aren’t the only persona that matters, though, far from it. One of the most important aspects of AWX is that it provides an entry point into Ansible for lots of roles other than developers. This is a conversation that frequently comes up. A team of developers might be using Ansible on the command line but they need to bring in folks who have expertise or insights that are relevant to their automation use cases. In lots of instances, those folks aren’t super comfortable with the command line. This is where a user interface becomes really valuable.

## Returning the Ansible UI to upstream

While refactoring the AWX codebase, the UI [was removed](https://github.com/ansible/awx/pull/15414). And while the `ansible/ansible-ui` repository was public, development activity had paused on that source code. This led to difficulty with community developers trying to run AWX, which came up in [GitHub issues](https://github.com/ansible/awx/issues/16117#issuecomment-3422997445).

You may have noticed the [Ansible UI: Development returns to upstream](https://forum.ansible.com/t/ansible-ui-development-returns-to-upstream/45756) post from Keith that announces that source code has been synchronized to the `ansible/ansible-ui` repository and that the Red Hat engineering team are back to working on the `devel` branch. That work complements the AWX modernization and completes another piece of the wider refactoring effort.

## Getting started with the Ansible UI

The Ansible UI codebase is in active development and you should expect to find some rough edges. Not everything is going to work out of the box when running AWX from the `devel` branch.

If you want to try it out, here is a quickstart:

1. Set things up.  
a. Fork or clone both the `ansible/awx` and `ansible/ansible-ui` repositories.  
b. Install requirements for Ansible UI following [GitHub - ansible/ansible-ui: The UIs for Ansible Projects such as AWX, EDA, and HUB. · GitHub](https://github.com/ansible/ansible-ui#getting-started)  
c. Install requirements for AWX: `dnf install docker docker-compose-plugin ansible openssl`

2. Stand up an AWX development environment.  
a. Open a terminal window in the root of the `ansible/awx` repository.  
b. Build the development image with `make docker-compose-build`.  
c. Start the environment with `make docker-compose`.  
d. Note the superuser password. You can also find this with `cat tools/docker-compose/_sources/secrets/admin_password.yml`.

3. Stand up an Ansible UI development environment.  
a. Open another terminal window in the root of the `ansible/ansible-ui` repository.  
b. Change to the `frontend/awx` directory.  
c. Enter `export AWX_SERVER='https://localhost:8043'`.  
d. Run `npm start`.

## Call to action

Reply to this forum post to share your thoughts and help shape the future of AWX. We also welcome contributions to improve the documentation for setting up development environments. If you hit any snags following the quickstart steps above, that is useful feedback in itself. We’d like to hear from you.

## Links in this AWX update series

- [Blog: Upcoming Changes to the AWX Project](https://www.ansible.com/blog/upcoming-changes-to-the-awx-project/)
- [Streamlining AWX Releases](http://forum.ansible.com/t/streamlining-awx-releases/6894)
- [Refactoring AWX into a Pluggable, Service-Oriented Architecture](http://forum.ansible.com/t/refactoring-awx-into-a-pluggable-service-oriented-architecture/7404)
- [Upcoming changes to AWX Operator installation methods](http://forum.ansible.com/t/upcoming-changes-to-awx-operator-installation-methods/7598)
- [AWX UI and credential types transitioning to the new pluggable architecture](http://forum.ansible.com/t/awx-ui-and-credential-types-transitioning-to-the-new-pluggable-architecture/8027)
- [AWX modernization: Moving forward](https://forum.ansible.com/t/awx-modernization-moving-forward/45134)
- [AWX modernization: Ansible UI](https://forum.ansible.com/t/awx-modernization-ansible-ui/45757) (this post)

## Useful links

- Forum: [AWX topics](http://forum.ansible.com/tag/awx)
- Forum: [Newsletter Category](http://forum.ansible.com/c/news/bullhorn/17)
- [AWX project documentation](https://docs.ansible.com/projects/awx/en/latest/)
- [AWX code repository](https://github.com/ansible/awx)

---

<div class="post-metadata">

**Author:** ![russoz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/russoz/32/127_2.png) [@russoz](https://forum.ansible.com/u/russoz)\
**Post date:** [May 1, 2026, 1:46am UTC](https://forum.ansible.com/t/awx-modernization-ansible-ui/45757/2 "2026-05-01T01:46:20Z")

</div>

Hi @thedoubl3j ,

Thanks for sharing this. Not sure when exactly, but I hope I can give it a spin on the build here - I am currently ~~working~~ hoping to building up my personal AWX at home.

I could not help to novice that you are building and starting the development image/env with `make`. Is that choice just something “we do because that’s how it’s been done since ever”, or is there a specific reason for it? I mean, these days I would think/recommend devcontainer for that kind of job. Is there a deliberate reason not to use devcontainer or was it just the inertial bearing? And, of course, if there is no pressing reason against devcontainers, would you consider using it? TIA

Cheers  
Alex

---

<div class="post-metadata">

**Author:** ![matteoclc](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/matteoclc/32/7020_2.png) [@matteoclc](https://forum.ansible.com/u/matteoclc)\
**Post date:** [May 7, 2026, 3:23pm UTC](https://forum.ansible.com/t/awx-modernization-ansible-ui/45757/3 "2026-05-07T15:23:25Z")

</div>

Just followed your instructions and I got AWX up and running flawlessly  
thanks

---

<div class="post-metadata">

**Author:** ![thedoubl3j](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/thedoubl3j/32/103_2.png) [@thedoubl3j](https://forum.ansible.com/u/thedoubl3j)\
**Post date:** [May 7, 2026, 3:35pm UTC](https://forum.ansible.com/t/awx-modernization-ansible-ui/45757/4 "2026-05-07T15:35:25Z")

</div>

Probably more of the “we have done it since ever”. We haven’t investigated devcontainer but are open to ideas most of the time. Make is tied pretty deeply into almost anything that builds containers (dev, CI, image building etc) so it might be more of a lift and is also used pretty extensively inside of our other projects. If folks want to investigate and try to mess around with it and get it working, I am not necessarily opposed to it but I am also only one person.
