Developing applications using Flatpak-packaged editors/IDEs

From reading the extensions description, this seems like exactly what it’s meant for. Means extensions for Atom, VSCode, etc. can be created per language (Python, Go, PHP, Ruby, etc.) which can contain all the tools needed for full language/IDE support (library, linter, etc.). I’m assuming a Flatpak extensions is easily distributed on Flathub and conveniently displayed in the GNOME Software app as add-ons to the main application. That makes it user friendly to extend your favorite editor with support for the required languages so the Atom/VSCode in-application extensions work too. Even makes it easy to scope extensions for major language versions (Python 2/3, PHP 5/7, etc.).

Anything with a wrapper requiring users to alter the language commands inside their editor to flatpak-spawn, or building all kinds of podman containers, or using fedora-toolbox is simply not user friendly. If we wanted to tinker with everything, we would probably all be using Gentoo. I know the solution is upstream in Flatpak/Flathub, but i.m.h.o. Fedora needs that to be a “it just works” solution.

1 Like

I just switched to running emacs from inside toolbox and I am way happier than I was with previously having it layered on the host, and trying to hook up e.g. M-x compile to run in my previous dev container. Also briefly tried GNOME Builder inside toolbox, seemed to work OK but I have too many years invested in Emacs at the moment.

This pattern of running GUI apps inside toolbox definitely has disadvantages too, e.g. GNOME Shell/Software doesn’t know about them, but on the flip side most editors and IDEs will Just Work this way to integrate with your build tools.

1 Like

toolbox create and toolbox enter are pretty user friendly. Also being able to use dnf as you would in workstation is pretty user friendly. The toolbox container idea was meant for developers, and can be tweaked to suit then trashed and rebuilt from scratch a different way. But it isn’t exclusively for dev’s, and it does provide a very neat rootless container to play around with some ideas in. If I could spin up a container for my windows app’s I need for my business I’d be overwhelmed by joy for finally being able to ditch the last vestige of a horrid OS. Instead of having to run it in a VM, ughh.

What I’m currently doing with VS Code is taking advantage of workspaces and the shell-args config option to automatically enter the toolbox for a project when I open the terminal while I have the project’s workspace open. I don’t get to use the Rust extension with the RLS this way (at least I haven’t gotten it to work yet) but I can adjust to not having it by getting in the habit of running Cargo Check often. IMO the containers are worth the workflow adjustments.

This is a cool idea, can you show an example of the config? I’d like to try that

Sure! I’m at work right now but I’ll post something tonight.

        "folders": [
                        "path": "<project folder>"
        "settings": {
                "terminal.integrated.shellArgs.linux": ["-c", "flatpak-spawn --host toolbox enter -c <container name>"]

So this is what my .code-workspace file looks like for one of my projects. This was generated automatically by VS Code. If you don’t want to use workspaces there’s also folder settings you can set in VS Code’s integrated settings editor. You can get to the settings editor with the gear in the bottom left corner. From there you switch to Workspace Settings and you’ll find the option under Features --> Terminal --> Integrated > Shell Args: Linux. The cool thing is that since these .code-workspace files are just json these could be created automatically with a script. I plan on writing a script that will automatically generate a container and a code-workspace automatically, and maybe also enter the container and install certain packages according to arguments given.


Thanks for sharing! I’d be interested in seeing how the script turns out. I haven’t really tried extending VScode that much. I suppose I should take another shot at it

Well the script I was thinking about writing either would be just a bash script or a small program, probably written in Rust. The code-workspace file is just a JSON file describing the path of the project and its workspace-specific settings, so you wouldn’t necessarily need VS Code to make it. As a matter of fact, that particular option just has you open the “settings.json” file (which is your workspace file if you are in workspace settings tab) and edit it manually anyway.

I ended up writing that script. Here it is if you want to check it out:


I’m assuming VScode’s remote development extensions only work with Docker containers? It would be great to be able to attach Flatpak VSCode to a running toolbox container.

edit: found a feature request for podman container support–needs more votes!

This will really make vscode great for silverblue, right now I am launching the IDEs from within the toolbox but this is so much better.

Gnome-Builder already does this pretty well, but when it comes to more exotic languages or frameworks(flutter, clojure, etc) vscode is my goto.

I use Atom and for golang development I did the following:

  • Created a new cgroup limited by CPU time:
group groupname {
  perm {
# who can manage limits
    admin {
      uid = 0;
      gid = 0;
# who can add tasks to this group
    task {
      uid = 1000;
      gid = 1000;
# create this group in cpu and memory controllers
  cpu { }
  memory { }

group groupname/foo {
  cpu {
    cpu.cfs_period_us = 1000000;
    cpu.cfs_quota_ns = 500000;
  • Updated toolbox to pass --cgroup-parent sandbox to new toolbox container
  • Created a new dedicated toolbox container - go-1.12 and installed golang from F30 repos
  • Created a script to generate wrappers for golang binaries:
prefix="flatpak-spawn --host podman exec -u 1000 -i"

bins=$(find $gobin -executable -type f)

for file in ${bins[@]} go gofmt; do
        echo -e "#!/bin/sh\n\n${prefix} ${container_name} $(basename $file) \$@" > ./$(basename $file)

chmod 0755 ./*
  • Generated wrappers for installed go binaries
  • Updated flatpaked Atom’s PATH to have a path for wrapper binaries first:
flatpak --user override io.atom.Atom --env=PATH=/var/home/vrutkovs/go/wrappers-bin:/app/bin:/usr/bin:/var/home/vrutkovs/go/bin

Now whenever Atom’s go-plus invokes go or any of its binaries these are in fact running in CPU limited container.

I didn’t try this method for VSCode yet though

Interesting approach. Has some advantages and disadvantages. I now use VS code installed in my toolbox container, and I basically live in the toolbox, running various utilities there (e.g. git-annex, random aws CLI invocations etc.) Having the editor just aware of golang binaries but not others would be…confusing I think? In particular I do use the integrated terminal in VS Code a lot.

I used to do the same, but I have many windows opened - and toolbox-based VSCode won’t merge them in a single app in Alt+Tab

I use a solution from Developing applications using Flatpak-packaged editors/IDEs

1 Like

I’ve managed to attach my Flatpak’ed VSCode to my Toolbox container via Remote-Containers extension. Instructions here:

Further discussion here:


Thanks for all your work on this to make this work with Flatpak. You are making it easier to use Silverblue as a daily developer desktop.

Hello @lbssousa,
I would like to welcome you to the community discussion area. Thanks for coming bearing gifts of knowledge.

I think Flatpaks should include ~/.local/bin in path. The entrie home directory is shared with host, so with this simple change, user can install tools needed by IDEs in ~/.local/bin and it will just work in the IDEs packaged in Flatpak.

I can see it is already done in toolboxes, binaries installed in ~/.local/bin just works in all toolboxes because toolbox shares home directory, and includes ~/.local/bin in $PATH already.

I sincerely hope people refrain from doing that.
Everyone can enable access to said directory through a simple override, why break the sandboxing default over this?

A graphical request based prompt for optional access to additional fs paths, upon the first execution of a newly installed Flatpak (or upon run with –permission-prompt), would be extremely useful users though.
The manifest file could include nested dictionaries of features paired with a description and all the filesystem/device/etc overrides required for it to be enabled.

I started a new related topic: Toolbox and Visual Studio Code Remote Containers - basically taking @lbssousa 's work with configuring Visual Studio Code Remote Containers extension and exposing it via a wrapper script that can be run from any toolbox.