[nickcharlton]

This is the cumulation of a lot of work to build a custom configuration which is practically fast enough to use. Previous attempts have either required too many configuration changes (or workarounds), taken too long to get started and be ready to use, or simply regularly broken.

The upstream universal image will track the supported versions of Ruby and Node used by this project, as that's most likely to always be the broadest requirements of any project.

The expectation is that anyone should be able to start a Dev Container (at least in Codespaces) to contribute to Administrate. It should have everything necessary to that, and not take too long for the environment to be ready.

https://github.com/thoughtbot/devcontainers
https://github.com/thoughtbot/codespaces-demo/tree/custom-config
#2948

[nickcharlton]

This has been so much work, but I'm glad it's working now. As I write this, a Codespace can start, and once you have a terminal you can run bundle exec rspec successfully.

In future we might want to try out prebuilds to make it even faster, and that should be just a case of configuring it (unless there's some work we can do differently to pre-cache some dependencies we want to do).

I'm not sure if we want to add more tools. Open an issue if so. If they're not something that's best done in dotfiles, we can add that to them to the universal image.

---

@goosys, here we go! Could you give this a go and see what you think?

[goosys]

@nickcharlton
Thank you!
I tried it, but I couldn’t pull the image. Is the image publicly available?
Here’s the error:

====================================== ERROR ====================================
2026-11-05 03:18:03.055Z: Failed to create container.
=================================================================================
2026-11-05 03:18:03.055Z: Error: Command failed: docker pull ghcr.io/thoughtbot/devcontainers/images/universal:latest
2026-11-05 03:18:03.055Z: Error code: 1302 (UnifiedContainersErrorFatalCreatingContainer)

====================================== ERROR ====================================
2026-11-05 03:18:03.061Z: Container creation failed.
=================================================================================
2026-11-05 03:18:03.070Z: 

[nickcharlton]

Oh, oops. I forgot about package visibility. They (all) should be public now.

[goosys]

@nickcharlton
Thank you!
The container built and the setup completed without any issues! It’s great that RSpec is ready to run right away!

However, the application started with bin/dev doesn’t work properly as-is. It needs host configuration and a CSRF workaround, as in this change:

https://github.com/thoughtbot/administrate/pull/2948/changes#diff-ee2248124f033964f85dd938b931137842fa9eaa1cee83c747e11b2484195033

I believe the universal Codespaces image provides RAILS_DEVELOPMENT_HOSTS, but it didn’t seem to be available in this container.

Perhaps we could use the following instead:

"#{ENV['CODESPACE_NAME']}-3000.#{ENV['GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN']}"

Also, if possible, it would be nice to have syntax highlighting in the editor. It works with the universal Codespaces image, but in this container, only the brackets seem to be colored.

[nickcharlton]

Nice, thanks for trying that!

I'll take a look at the CSRF stuff, there's probably something the others are doing which I didn't notice.

Do you know what's causing the syntax highlighting? It might be that we want to explicitly use the Ruby plugin (I'm not a big VS Code user, so bear with me!)

[nickcharlton]

I've just added the Ruby LSP VS Code extension after looking through the universal and Ruby images (and feature) to see what they did.

I cannot seem to work out where the CSRF stuff is actually implemented though, very weird.

[nickcharlton]

Oh wait, it's here: https://github.com/devcontainers/images/blob/main/src/universal/.devcontainer/local-features/setup-user/devcontainer-feature.json

[goosys]

The original universal image also had syntax highlighting without the Ruby LSP extension. I’ve now confirmed that simply reselecting a VS Code color theme after startup enables syntax highlighting in the custom container.

Installing Ruby LSP alone doesn’t seem sufficient, since files such as JSON, YAML, and HTML still aren’t highlighted.

Ideally, there would be a way to automatically apply the default theme on startup while respecting each user’s theme preference.

[nickcharlton]

The original universal image also had syntax highlighting without the Ruby LSP extension. I’ve now confirmed that simply reselecting a VS Code color theme after startup enables syntax highlighting in the custom container.

I think because the universal image brings in the Ruby feature you get it, because it's a combination of the feature definition. But I don't understand why you'd get that behaviour, unless it's just a bug.

---

I just added the RAILS_DEVELOPMENT_HOSTS environment variable, so hopefully that works now.

(Once this all works, I'll upstream it into the image definition.)

[goosys]

Just to clarify, syntax highlighting already works in the custom container without installing any additional extensions—I only need to reselect a color theme after startup.

What I’m trying to figure out is how to configure the custom container so that a theme is applied automatically on startup, without forcing everyone to use a particular theme.

[goosys]

Also, I don’t think adding RAILS_DEVELOPMENT_HOSTS alone will resolve the Rails issue. The CSRF workaround from #2948 is still needed because of a Codespaces-side bug. Host configuration alone doesn’t address that.
https://github.com/orgs/community/discussions/156532

[nickcharlton]

What I’m trying to figure out is how to configure the custom container so that a theme is applied automatically on startup, without forcing everyone to use a particular theme.

Are you using any of the VS Code settings sync or dotfiles functionality?

Also, I don’t think adding RAILS_DEVELOPMENT_HOSTS alone will resolve the Rails issue.

Ah yes, I see now, sorry I didn't entirely read what you wrote 😅

[goosys]

Are you using any of the VS Code settings sync or dotfiles functionality?

Thanks for the suggestion! Now that I know I can get syntax highlighting working by simply reselecting a color theme after VS Code starts, I’m happy to use that workaround. No need to spend more time on this!

[nickcharlton]

Alright, cool! Let me know anything else that comes up. I'm curious to know about what's surprising, what's unexpected, and what's generally broken. Once we fix the final things with this and it gets merged, a Discussion thread is probably a good place to put that.

---

I've been trying to understand what's going on with the connections to port 3000 and pushed a change much like your previous one earlier, but it's still not working. It seems like it only actually works if the URL is made public, which I think is no good.

My current Codespace (running on 37c5694) just gives me:

The server at sturdy-space-winner-r7w4rpj7c5v-3000.app.github.dev sent back an error: 401 Unauthorized

...and that's when running it in a new browser window, because Firefox doesn't like the embedded one.

@goosys, could you try and see if works? I'm finding it weird I can get this to work despite it being the common solution everyone's settled on.

[goosys]

This is another long-standing quirk of Codespaces. Briefly switching the forwarded port’s visibility to Public and then back to Private makes the application accessible through the forwarded port.

I’ve just started a Codespace with the latest commit, and both the host configuration and the CSRF workaround are working correctly. The application is running as expected now. Thank you!

[nickcharlton]

Ah, excellent! I'll tidy everything up once I can actually get it working for myself. Even that port visibility one didn't work for me.

I've now tried both Firefox and Chrome on Debian and had the same outcome, so I don't know what's going on here.

[nickcharlton]

I've tidied this up, after moving some of the changes back upstream and now I think this is good to go.

I'm going to merge it now because @goosys confirmed it's working nicely for them, and I've tested it a bunch myself.

After this is done, I've got a few more things to do in the upstream project, but initially that's going to be a bit more documentation and finding out anything else that's missing.