sway ports your i3 config, not your desktop

Copying the i3 config is the migration, and it is only a config

The compatibility claim is concrete and narrow. If you already use i3, you copy your i3 config to ~/.config/sway/config and it works out of the box. If you do not, you copy the sample configuration, which is usually at /etc/sway/config, and start from there. The reference for what the file can contain is the manual: man 5 sway. What travels with that file is the configuration language, the keybindings, the tiling behaviour and the layout rules. What does not travel is everything that was a separate program on your i3 system. A launcher, a screen locker, a notification daemon and the panel applets you were used to are not among the programs in this repository. So the honest way to read the compatibility line is that it ports your muscle memory, not your desktop.

Four binaries ship, and only one of them is the compositor

The top level of the repository shows the scope. There is sway/ for the compositor itself, then swaybar/, swaymsg/ and swaynag/ as separate directories, alongside client/, common/, include/, protocols/, completions/, assets/, config.in and sway.desktop. swaymsg is the command line client you script against, swaybar draws the status line, and swaynag is the small dialog tool.

meson, ninja, and four dependencies that must exist at build time

Building is three commands:

meson setup build/
ninja -C build/
sudo ninja -C build/ install

The dependency list is longer than that command, and the asterisks in it are the part worth reading. Four entries are marked as compile-time dependencies: meson itself, wayland-protocols, scdoc and git. The last two are there for reasons that are not obvious from the names. scdoc generates the man pages, so without it there is no man 5 sway and no configuration reference on the machine. git is for version info. Then there are the optional ones, and each of them removes a feature rather than failing the build. gdk-pixbuf2 is optional and adds image formats for the system tray, swaybg is optional and provides the wallpaper, scdoc is optional and produces the man pages. A build without them starts cleanly and quietly lacks things.

Releases are signed with one key, and 1.12 is the current line

Supply chain details are stated rather than implied. Releases are signed with the key identified as E88F5E48 and published on GitHub releases, with a link to the key on keys.openpgp.org, so there is a specific artefact to check a tarball against rather than a general assurance. The recent tags show a normal release cadence with candidates published first: 1.12-rc2 on 2026-04-12, 1.12-rc3 on 2026-04-26, and 1.12 on 2026-05-25. The last push recorded for the repository is 2026-09-21, which is four months after the release. So there are three versions of the compositor in play at any moment, the distribution package you install, the release tarball you can verify against the signing key, and the branch, and they are not the same code. The wiki has a separate development setup page for building the HEAD of sway and wlroots together, which is a different activity from installing a release.

Twenty-seven translated READMEs, and one English man page

The language links at the top of the file run from English through Arabic, Azerbaijani, Czech, German, Danish, Spanish, French, Georgian, Greek, Hindi, Hungarian, Persian, Italian, Japanese, Korean, Dutch, Norwegian, Polish, Portuguese, Romanian, Russian, Serbian, Swedish, Turkish, Ukrainian and both Chinese scripts, and the repository carries a README file for each. That is a real maintenance commitment. The man pages come from scdoc, and the dependency list shows no translation step for them.

Starting sway means taking over the session, from a TTY or a display manager

The documented way to run it is to run sway from a TTY or from a display manager, and sway.desktop at the top of the repository is the entry for the second path. The config is one file, it lives in your home directory, and it is plain text, so keep it somewhere you can read from another machine. Anyone automating a sway setup should do the same with the sample config as a starting point rather than typing a config from memory.

wlroots is where the hardware and protocol support is decided

wlroots is a required dependency, not an optional extra, and the development setup page in the wiki covers building the HEAD of sway together with the HEAD of wlroots. That boundary matters when something breaks. The Wayland protocol handling, the DRM and libinput paths and the output management all come from wlroots, so a regression that surfaces as sway misbehaving on a new kernel or a new GPU may have started one layer down, and pinning sway alone does not pin what it sits on. It also explains the shape of the project. sway is a compositor with a compatible configuration language; a usable Wayland session is what you assemble around it from wlroots, swaybar, swaymsg, swaynag and the rest. The project is deliberately not that assembly, which is why the repository is small enough to read and why the surrounding choices stay yours.

Editorial conclusion

sway fits someone who already lives in i3 and wants the same keybindings on Wayland without learning a second window manager. It does not fit someone expecting a desktop, because the compositor, the bar, the IPC client and the nag tool are four separate programs and only the config format is inherited from i3. Before you install, read the dependency list rather than the compatibility claim: gdk-pixbuf2, swaybg and scdoc are all optional, so a build that skipped them has a limited system tray, no wallpaper and no man page, while meson, wayland-protocols, scdoc and git are marked as compile-time dependencies. Then decide how you will start it, from a TTY or through sway.desktop from a display manager, and keep that config file in version control.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. swaywm/sway on GitHub