DebNAS: a shell script that turns Debian into a quasi-NAS
一个将Debian快速配置成准NAS系统的脚本。
At a glance
- What is it?
- debnas is a single shell script that configures a Debian 12 or 13 host into a NAS-oriented server with a Cockpit console for the system and Portainer for Docker, on amd64 only and with no tagged releases to pin.
- Who is it for?
- DebNAS suits a person who already runs Debian 12 or 13 on amd64, wants a home NAS with a browser interface, and is comfortable executing a script as root over SSH. It does not suit a buyer who expects a supported appliance, a team that needs a rollback path or an audit trail, or anyone on Ubuntu or ARM hardware, where the project itself points to a manual build.
- 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 68 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The gap DebNAS fills: NAS functions without a NAS operating system
DebNAS addresses one specific gap. Many people want a home NAS with a browser interface, but the packaged NAS appliances ask you to run their own operating system and accept its release cycle. This project takes the other route. It is a shell script that configures a Debian 12 or Debian 13 machine into what the project calls a quasi NAS, adding file sharing, photo backup, home media, Docker and virtual machine management, and RAID setup behind a web interface.
The audience is narrow, and it is worth saying so early. The reader is someone who can install Debian from a minimal image, open an SSH session, and elevate to root. If that is your workflow, the script removes a long list of manual steps. If you want a turnkey box that arrives with storage, user accounts and a support arrangement already configured, this is the wrong shape of tool.
The project's own demonstration is the clearest statement of the intended result. On an ASRock J3455 board with 16 GB of memory running Debian 12, the setup holds one virtualized Synology DSM 7.2 instance and 36 Docker containers, with daily CPU usage around 30 percent. That combination is telling: the host stays a general Debian system, and anything that needs a dedicated appliance operating system runs as a guest on it.
One install.sh, and the -s argument that picks the mirror and the branch
The entry point is a single file, install.sh, kept at the top level of the repository next to bin/, config/, docker-compose/, lib/, modules/, LICENSE and README.md. That layout suggests a modular script: a driver at the root, shared helper code under lib/, individual tasks grouped under modules/, declarative configuration under config/, and container definitions under docker-compose/. The project publishes a script introduction page on its own documentation site, which is where the module list and the execution options are described, since the repository carries no inline module documentation.
Execution happens by streaming the script straight into bash. Two mirrors exist, GitHub and Gitee, and the choice is passed through a single -s argument whose format is platform at branch, for example github@main or gitee@dev. The branch component is the useful part. The same command shape can pull the main branch or a development branch without editing the URL, which is the only version selector the project offers, because the repository declares no GitHub releases.
Worth noting for a security-minded reader: the script is fetched and executed in a single step, so nothing lands on disk for review first. The source is public and readable in the repository, and the branch argument lets you point at a specific revision, but the default path gives you no chance to read what is about to change packages, services and firewall rules on the machine.
From minimal Debian to two web consoles on 9090 and 9443
Installation starts before the script, with a minimal Debian installation and an SSH connection to the host. The project links a Debian minimal installation guide for that step. Two details matter before anything is downloaded. Debian blocks root login over SSH by default, so you sign in with the regular user account created during installation. Then you switch to root inside that session, and the project gives the exact command.
su -With root active, you run the install command. The GitHub and Gitee variants are alternatives, and the project marks the Gitee mirror as the recommended option for users inside China.
bash <(wget -qO- https://raw.githubusercontent.com/kekylin/debnas/main/install.sh) -s github@mainbash <(wget -qO- https://gitee.com/kekylin/debnas/raw/main/install.sh) -s gitee@mainWhen the script finishes, the SSH console prints the addresses of the two web consoles. Cockpit, described in the project notes as a graphical desktop for the server, is the system management side and is reachable at the following address.
https://localhost:9090Portainer is the Docker management side, offering container status, application templates, image and volume handling, event logs, container consoles, and Swarm cluster and service views, at this address.
https://localhost:9443Cockpit authenticates with ordinary system accounts and disables root login by default, so the account created during the Debian installation is the one to use.
Debian 12 and 13 on amd64, and nothing else
The automation is narrow by design. The script supports Debian 12.x and 13.x on amd64, and the project states plainly that other systems and architectures, Ubuntu and ARM among them, are outside the supported range. The reason given is that the author optimized and tested against those two releases given limited time and energy.
The same passage offers a consolation that deserves to be taken seriously. For other environments, the advice is to read the architecture and configuration ideas in the project documentation and build the equivalent setup by hand. That makes DebNAS partly a written design plus a convenience script. If your server is not Debian 12 or 13 on amd64, you are not its audience, and no change to the -s argument will make it one.
The second constraint is the resource footprint. Running a Synology DSM 7.2 instance as a virtual machine, as the demonstration does, alongside 36 Docker containers on 16 GB of memory means planning memory before you copy that configuration. The 30 percent daily CPU figure describes one particular board and one particular workload, not a guarantee for your hardware.
No tagged release means no rollback path either
DebNAS executes code that it downloads at the moment you run it, with root privileges, on a machine meant to hold photos and files. The command form is a piped download, so there is no local copy of install.sh to read before it starts. Anyone evaluating the project can open the script in the repository first, and the branch argument lets you select a revision, but the run itself leaves a machine in a new state.
That is the real operational difference from assembling the same stack by hand. A manual build leaves a trail of individual commands you can review, repeat, and undo. A single scripted pass leaves you with the end state. The project does not document a rollback procedure, so there is no stated way to return a machine to its condition before the run.
Two more documentation gaps matter for anyone planning a deployment. The repository has no GitHub releases, so there is no numbered version to pin and no changelog to read before upgrading. The upgrade path in practice is the branch argument, which means the same command that installs a system can also pull in a different code state later. The project does not describe how to upgrade an existing installation in place.
How DebNAS differs from an appliance-style NAS
NAS software comes in two broad shapes, and DebNAS belongs to the second. One shape is an appliance-style system where storage, sharing, and account management are the operating system itself. The other is a general purpose Linux host on which NAS functions are assembled from parts: a server console for the system, a container manager for applications, and storage arrangement handled separately.
DebNAS takes the second route and makes it repeatable. On the demonstrated host the parts are visible in the repository layout and in the two consoles the script installs. A Synology DSM 7.2 instance runs as a virtual machine, which keeps that appliance interface available if you want it, but as a guest rather than as the host system. The project also positions itself for home lab and homelab use, and its topic list connects it to the surrounding ecosystem of media servers, virtualization platforms, and container tooling.
The practical difference for an engineer is control over the base system. You keep a normal Debian installation that remains reachable over SSH, and the NAS layer sits on top of it as services and containers. The cost is responsibility: you must keep that base healthy yourself, and the project covers one distribution release pair, so there is no breadth of platform support to fall back on.
Maintenance signals, a QQ group, and the GPL-3.0 licence
On maintenance, the repository is not archived and the last push was on 2026-08-16. There are no GitHub releases, so version history lives in commits rather than tagged artifacts, and upgrades are driven by the branch argument to the install command. The project lists a QQ group, 339169752, as its support channel, which is a reasonable expectation for a single author project but is not a substitute for release notes or an issue tracker with public history.
The repository is licensed GPL-3.0. That matters for two groups of people. For anyone redistributing or modifying the script, a modified version carries the same licence and its source has to be made available under GPL-3.0 terms. For anyone assembling a system from it, the script pulls in other software, including the container definitions in docker-compose/, and each of those components keeps its own licence, so the licence of the finished system is not simply the licence of install.sh. This is a reading of the licence terms rather than legal advice.
A final practical point ties the licence and the upgrade story together. Because a run downloads a script rather than installing a pinned package, the state of your machine depends on the branch you pointed at that day. Keeping a note of the branch used for the first installation is the cheapest way to know what you are running later.
Editorial conclusion
DebNAS suits a person who already runs Debian 12 or 13 on amd64, wants a home NAS with a browser interface, and is comfortable executing a script as root over SSH. It does not suit a buyer who expects a supported appliance, a team that needs a rollback path or an audit trail, or anyone on Ubuntu or ARM hardware, where the project itself points to a manual build. Before running install.sh, read it, check that the modules under modules/ and the services under config/ match what you intend to run, and compare your memory budget against the demonstrated workload of one virtual appliance and 36 containers. After the first run, record the branch you used, because the project has no release tag to return to.
Frequently asked questions
Which operating systems does debnas support?
The automation covers Debian 12.x and 13.x on amd64 only. The project states that other systems and architectures, including Ubuntu and ARM, are outside the supported range, and suggests following the documented architecture manually for those environments.
How do I install debnas on a Debian server?
Log in over SSH with the regular user created during the Debian installation, switch to root with su -, then run the install command that pipes install.sh into bash with a -s platform@branch argument. The project offers a GitHub mirror and a Gitee mirror, and marks the Gitee one as recommended for users inside China.
Which web interfaces does debnas set up and on what ports?
The script installs two consoles and prints their addresses when it finishes: Cockpit for system administration at https://localhost:9090, and Portainer for Docker management at https://localhost:9443. Cockpit uses ordinary system accounts and disables root login by default.
Does debnas have versioned releases I can pin to?
No. The repository has no GitHub releases, so the branch passed to the -s argument, such as github@main or gitee@dev, is the version selector the project offers. The last push was on 2026-08-16.
Official sources
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.
[](https://hysenlabs.com/projects/kekylin-debnas)Was this useful?