Open-source project
Keyitdev/dotfiles avatar
Keyitdev/dotfiles

Keyitdev dotfiles: an i3 and Arch Linux desktop you copy over your home directory

Arch dotfiles. i3 dotfiles.

583 stars43 forksCSSGPL-3.0

At a glance

What is it?
The Keyitdev dotfiles repository mirrors the filesystem so applying it is a copy command, giving an Arch Linux machine with i3, a Kitty terminal, Polybar, Rofi launchers, Picom compositing and a set of small shell scripts for brightness, volume and power. The install instructions are unusually complete, down to the pacman package lists and the udev rules.
Who is it for?
Adopt the Keyitdev dotfiles if you want a complete i3 desktop on Arch Linux and are willing to start from the package list the author chose, since the configuration is designed around a specific set of tools and copies over your home directory. Do not adopt them on a machine where you have existing configuration you care about, because the install step copies into $HOME and /usr rather than merging carefully.
Can I use it commercially?
Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
Is it still maintained?
Yes. The repository last received commits 19 days ago.
What is it written in?
Mainly CSS, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.

Editorial analysis

The core idea: the repository is a copy of the filesystem

These dotfiles are built for a simple and efficient Arch Linux environment using i3 on X11 as the window manager, and the design decision that makes them different from most dotfile repositories is stated in one sentence: the repository mirrors the directory structure of the operating system, so to apply the configurations you simply copy the files into your system.

That is a real simplification compared with the more common approaches. There is no stow or chezmoi or a bootstrap script that symlinks individual files. The home directory in the repository is your home directory, and the usr directory in the repository is the system usr directory.

The consequence is that you can read a configuration file in the repository and know exactly where it will land, which is a genuine advantage when you are trying to understand what a setting does. The cost is that applying the configuration is a bulk copy rather than a set of individual file placements.

The README also sets expectations about the package list. It includes many optional packages and tools that the author personally uses, and you do not need to install all of them, with a pointer to the detailed information section for the breakdown.

The repository is GPL-3.0 licensed, the default branch is v4, and older versions of the setup are kept on other branches, which the README links. The last push was on 2026-10-04 and there are no GitHub releases, so the branches rather than the tags are the version history. The topic list names the tools involved: i3 and i3-gaps, Kitty, Alacritty, Polybar, Rofi, zsh, and the unixporn and rice tags that describe the genre of desktop this belongs to.

The install path, from pacman to a copied home directory

The installation section is a numbered sequence, and it is one of the more complete install guides you will find in a dotfiles repository, because it starts from a bare system.

The base system comes first, with a single pacman invocation covering the essentials:

sh
sudo pacman -S --needed archlinux-keyring base base-devel linux linux-firmware git pulseaudio xorg xorg-xinit 

Then yay, the AUR helper, is built from the AUR itself:

sh
git clone https://aur.archlinux.org/yay-bin.git "$HOME"/.srcs/yay && cd "$HOME"/.srcs/yay/ && makepkg -si

And then the dependencies, which is the long list that defines which programs the configuration expects:

sh
yay -S --needed btop code dunst fastfetch feh i3-wm i3lock-color kitty mate-polkit mpd ncmpcpp papirus-icon-theme picom polybar rofi xss-lock zsh zed ttf-roboto-mono ttf-opensans ttf-iosevka-nerd ffcast inotify-tools jq libnotify rofi-vscode-mode scrot slop upower xclip

The copy step is the core of it:

sh
git clone -b v4 --depth 1 https://www.github.com/keyitdev/dotfiles.git "$HOME"/dotfiles
cp -ri "$HOME"/dotfiles/home/. "$HOME"/
sudo cp -ri "$HOME"/dotfiles/usr/.  /usr/

The branch flag matters, since v4 is the default branch of the repository, and the depth 1 flag keeps the clone small. The copy flags are the interesting part: -r is recursive and -i is interactive, so the copy asks before overwriting an existing file. That is a deliberate safety property in a command that writes into your home directory and into /usr.

Finally the shell change:

sh
chsh -s /bin/zsh

The README then notes that your system may still be missing important programs such as a media player or even a web browser, and that the following steps are optional but worth checking out.

Networking, optional packages and the services you switch on

The optional extras are grouped into short, self-contained blocks, and each one is a real decision rather than filler.

Networking comes first, since without it a fresh Arch install has no connection:

sh
yay -S dhcpcd iwd
sudo systemctl enable --now dhcpcd.service iwd.service

The enable --now pattern is worth noticing: it both enables the unit for future boots and starts it immediately.

The optional package lists are then organised by theme rather than by size. A general utilities block covers bc, dmenu, downgrade, fzf, mpc, nano, vim, net-tools, ntp, tree, vi and wget. A desktop applications block covers 7zip, czkawka-gui, the several Firefox variants, gimp, inkscape, gparted, libreoffice-fresh, mpv, vlc, nemo, obs-studio, obsidian, qalculate-gtk, rsync, vnstat and yt-dlp. A hardware block adds cpupower-gui, ntfs-3g, nvidia, cuda, nvtop and vulkan-radeon. A development block covers cloc, cronie, docker, gcc, clang, make, npm, python, pypy, numpy, pandas, scipy, matplotlib, requests and tmux. And a font block adds the noto-fonts family including the CJK and emoji variants.

The hardware block is the one to look at closely, because it is the part that is machine-specific. The nvidia and cuda entries assume a discrete NVIDIA setup, and vulkan-radeon assumes an AMD or Intel GPU with Vulkan support. Installing both on a machine with one or the other is harmless but pointless, and the driver choice for your hardware is the first thing you should adjust.

The optional services are enabled separately, and the choice of daemon matters here. The README enables ntpd.service and vnstat.service:

sh
sudo systemctl enable ntpd.service
sudo systemctl enable vnstat.service

vnstat is a network usage monitor, so enabling it means it starts collecting bandwidth statistics. The README does not discuss the interaction with the dhcpcd and iwd services you enabled earlier, and on a system where a different time daemon is already running, having two is worth avoiding.

What is in the tree, and what the scripts in /usr/local/bin do

The detailed information section includes a full directory tree, and it is the clearest statement of what the configuration covers.

The home directory holds a .config directory with per-application configuration for alacritty (alacritty.toml plus colors.toml), btop, Code - OSS, dunst, fastfetch, gtk-3.0, gtk-4.0, i3, kitty, mpd, ncmpcpp, .obsidian, picom, polybar, rofi and zed. There is also a Pictures directory with wallpapers and a background image, a .xinitrc and a .zshrc.

Two details in that list are worth noting. Both alacritty.toml and colors.toml are present, and the rofi directory has a colors.rasi, a dmenu.rasi, a main.rasi and a main_without_icons.rasi, so the colour scheme is factored out across the applications that use it rather than duplicated per file. And the presence of both i3 and the alacritty and kitty configuration suggests the author moved between terminals and kept both.

The usr directory is where the custom scripts live, and it is the more unusual half of the repository. Under usr/lib/udev/rules.d there is a single rules file, 90-light-backlight.rules, which handles the keyboard backlight at the udev level.

Under usr/local/bin there is a set of small shell scripts: asus_fan_listener, asus_fan_toggle, battery_listener, brightness_control, brightness_level, microphone_mute, volume_control, volume_level, volume_mute, and a lock script. Alongside them are a screenshot script, a touchpad_toggle and a rofi-powermenu, and a set of SVG icons for battery, microphone, sun, moon and the volume levels, plus a rofi-screenshot script.

That list is a good description of what a tiling window manager setup actually needs beyond the window manager itself. The hotkeys in i3 call these scripts, and the scripts call the system tools. The asus_fan entries and the backlight udev rule are the hardware-specific pieces, and they are the ones that will not work on a different machine without editing.

The dependency breakdown, and the parts of a desktop nobody writes down

The README has a dependencies section that breaks the package list down by size, starting with a base group of roughly 190 Mib. The base group is archlinux-keyring, base, base-devel, linux, linux-firmware, plus git as the version control system and pulseaudio as the sound server for handling audio, with dhcpcd as the optional DHCP client and iwd as the optional wireless network daemon, and xorg as the display server component.

The grouping by footprint is the useful idea here, and it is something most dotfiles repositories skip. A new user can see roughly how much disk the base costs before installing anything, and then decide whether the optional groups are worth it.

The README also has a support and contributions section with a set of house rules that are unusually direct. Issues are welcome, but you should check the issues tab first to avoid creating duplicates, and when opening an issue you should provide detailed information about the problem, with the reasoning stated plainly: the author cannot help if you just write something like this thing is not working, so include as much relevant information as possible.

Before starting work on a pull request for a new feature, you are asked to open an issue first so it can be discussed. And there is a rule about pull requests themselves that stands out: avoid overusing AI, with the note that we do not need 500 emojis, and that more lines of code does not mean better code, so focus on simplicity and quality.

That last instruction is a fair summary of how to treat this repository. The configuration is small, mostly plain text files in the XDG layout, and the value is in the curation rather than in the code. A contribution that adds a tool the author does not use, or rewrites a working config for style, is not what the project is asking for.

Editorial conclusion

Adopt the Keyitdev dotfiles if you want a complete i3 desktop on Arch Linux and are willing to start from the package list the author chose, since the configuration is designed around a specific set of tools and copies over your home directory. Do not adopt them on a machine where you have existing configuration you care about, because the install step copies into $HOME and /usr rather than merging carefully. Before you run it, read the dependency list, decide which of the optional packages you actually need, and check the other branches, since older versions of the setup are kept there and this one lives on the v4 branch.

Frequently asked questions

How do I install the Keyitdev dotfiles?

Install the base system with pacman, build yay from the AUR, install the dependency list with yay, then clone the repository on the v4 branch and copy the home and usr directories into place with cp -ri, and finally set zsh as your shell with chsh -s /bin/zsh.

Why does the Keyitdev dotfiles repository copy files instead of using symlinks?

The repository mirrors the directory structure of the operating system, so a config file's path in the repository is the path it occupies on the system. The install is a recursive interactive copy of the home and usr directories, with the -i flag asking before overwriting existing files.

Which programs does the Keyitdev i3 configuration expect?

The dependency list names btop, code, dunst, fastfetch, feh, i3-wm, i3lock-color, kitty, mate-polkit, mpd, ncmpcpp, papirus-icon-theme, picom, polybar, rofi, xss-lock, zsh and zed, along with the ttf-roboto-mono, ttf-opensans and ttf-iosevka-nerd fonts.

What custom scripts come with the Keyitdev dotfiles?

Under usr/local/bin there are asus_fan_listener, asus_fan_toggle, battery_listener, brightness_control, brightness_level, microphone_mute, volume_control, volume_level, volume_mute, lock, screenshot, touchpad_toggle, rofi-powermenu and rofi-screenshot, plus SVG icons, and usr/lib/udev/rules.d contains a 90-light-backlight.rules file.

Do I have to install every package listed in the Keyitdev dotfiles?

No. The README says the repository includes many optional packages and tools that the author personally uses and that you do not need to install all of them, with the dependency section broken down by group so you can pick the ones you want.

Official sources

  1. Issues
  2. Keyitdev/dotfiles on GitHub
  3. License: GPL-3.0
  4. README
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/keyitdev-dotfiles.svg)](https://hysenlabs.com/projects/keyitdev-dotfiles)

Was this useful?