F45 Change Proposal: Encapsule isolated devel containers (self-contained)

Project Discussion Change Proposals
,
1

Encapsule isolated devel containers

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

encapsule is a new small CLI tool for developers who want to try out “tools installed from the internet” for example (or use them within a project workdir) inside a safer container environment rather than directly in their home directory and host system.

:link: Owner

:link: Detailed Description

The CLI tool allows running developer containers, isolating your home directory and host from container side effects: it can “encapsule” a project and/or temp homedir there together with select enabled “capabilities”. It uses Podman to run a (derived) container image (which can be generated by Buildah from a toolbox container say). The project readme file has more details about the specific features and commandline options.

In this age developers are frequently asked to install and run all kind of commands or software directly from the internet whether from source or more often now binaries. In recent years curl https://some.project/install.sh | bash or npm/npx install ... (and many others: pip, cargo, etc) are being normalized and can both pollute one’s home directory or system, and also put it at increased security risk. encapsule provides a lightweight, somewhat safer environment for installing and running such tools. Note however it is not intended for running known malicious programs or security testing, etc - though at least it provides some basic separation or system hygiene. Users can also disable sudo or even the network (or potentially DNS) inside the encapsule container.

In many ways it makes opposite design choices to toolbox: closed by default rather than open - but one can opt in to sharing specific things from the host.

A lot of the original ideas are derived from toolbox-constrained by Sebastian Wick, without which this tool probably wouldn’t exist now in its current form.

For more hardened isolation it is recommended to look at OpenShell though it is not available yet in Fedora. In the future it may be possible to migrate encapsule to wrap openshell for instance and use its gateway perhaps, which would enhance network isolation considerably.

The alternative is to use a VM of course, but that is much more heavyweight and awkward: though there is the similar whot/schupfn project, which allows exporting specified directories with 9p to a QEMU VM instance, also generated from a toolbox.

:link: Feedback

:link: Benefit to Fedora

Fedora users will have a simple way to isolate toolbox containers etc from their homedir and host system for running third party tools inside a contained environment, where they control what is shared from their home or host system.

:link: Scope

  • Proposal owners:

    • Submit encapsule for package review and get it approved
    • Fix reported issues and improve further

  • Other developers: N/A

  • Release engineering: #Releng issue number

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

:link: Upgrade/compatibility impact

N/A

:link: Early Testing (Optional)

:link: How To Test

:link: User Experience

Users will have a safer way to run harnesses and other tools grabbed from the internet.

:link: Dependencies

:link: Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change)

:link: Documentation

N/A (not a System Wide Change)

:link: Release Notes

To be written

Last edited by @amoloney 2026-07-22T14:57:38Z

Last edited by @amoloney 2026-07-22T14:57:38Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

1 Like
3

Looks interesting, but a process question - does this need to be a Change Proposal tied to a release?

Could it be dealt with just like adding any other new package to Fedora?

4

Thanks, the reason for highlighting the package is that it is highly relevant at this time, when many users are increasingly installing CLI tools directly from the internet and particularly now making frequent use of such agent harnesses. Encapsule can provide basic easy isolation of such tools from one’s system, only sharing what they need to see.

I am about to release version 0.4 which introduces subcommands and other changes, btw.

Also I could add I am not completely enamored with the name (it started as constrained-toolbox, then I briefly tried envclave locally, and now encapsule). I think it is an okay name though not the easiest to type (basically enca+Tab to complete). If there is a better name I could still consider renaming. Note currently the name is used to prefix the “encapsule” container names.

5

Would you think fence would be better?

Or maybe hegne! :slight_smile: