# SadServers: A Linux Troubleshooting Practice Ground Built on Real Servers

> SadServers is a SaaS that drops you into an ephemeral Linux VM with a broken system and a test to pass. This review covers how the platform is wired, how to start your first scenario, and where it falls short.

**SadServers/sadservers** — SadServers: Linux & DevOps Troubleshooting Scenarios SaaS

- Repository: https://github.com/SadServers/sadservers
- Website: https://sadservers.com
- Stars: 3,001 · Forks: 118
- Language: HCL
- License: not declared
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/sadservers-sadservers

## What SadServers Actually Is and Who It Is For

SadServers is a hosted service where you get a shell on a real Linux server that has something wrong with it. The README describes it as a SaaS for practicing Linux and DevOps troubleshooting in a Capture-the-Flag format. Each scenario gives you a description of the fault and a test that decides whether you solved it. The server is created for you, you connect through a browser window that behaves like SSH, and the instance is destroyed when the allotted solving time runs out.

The target audience is narrow and clearly stated: professional software developers, system administrators, DevOps engineers, and SREs, plus people interviewing for those roles. The README says the project wants to test these professionals in a way that is useful for the troubleshooting portion of a job interview. That framing matters, because it explains why scenarios lean on real software such as databases and web servers rather than abstract puzzles. Some scenarios, like the Docker one the README mentions, do expect familiarity with the specific technology; others do not.

Companies also use it, according to the README, to automate or facilitate Linux troubleshooting interviews and for internal training. That is a different use case from individual practice, and it changes what you care about: reproducibility and fairness matter more than variety.

## How a Scenario Runs: Django, Celery, RabbitMQ and Ephemeral VMs

The architecture is more conventional than the product might suggest. A Django application with Python 3 serves the site, sitting behind Nginx and Gunicorn. Bootstrap and plain JavaScript handle the front end. SSL comes from Let's Encrypt via certbot.

When you request a server, the work does not happen in the request cycle. New server requests are queued and processed in the background. Celery manages those tasks asynchronously with a RabbitMQ backend, and task results are written to the main database. The front end shows progress using the Celery Progress Bar for Django package. Instances are requested from AWS with Boto3, based on scenario images, and a Celery beat scheduler checks for expired instances and kills them. That beat scheduler is the piece that makes the model work: without it, abandoned VMs would accumulate.

The network design is the part worth paying attention to. Users interact over HTTPS only with a web server and a proxy server that connects to the scenario VMs. Everything else is internal, between VPCs or AWS services. Each scenario VM lives in a VPC with no Internet-facing incoming access and limited egress. For a service that hands strangers a root shell on a machine, that isolation is the whole security story, and the README treats it as such.

The README also documents two features that are easy to miss. There is a replay system, and there are resumable VMs. Both appear in the table of contents alongside the API and scenario command history logging. The repository top level includes replay_system.jpg, instance_lifecycle.png, vm_logging.jpg, and command_history.png, so these are documented subsystems rather than roadmap items. Command history logging is notable for the hiring use case: it is what lets an employer see how a candidate approached a problem, not just whether they passed.

## Installing Nothing: Starting Your First Scenario in the Browser

There is no package to install and no local setup. The README points to sadservers.com, and the entire interaction is a browser session against a server the platform creates for you. If you were expecting a CLI or a Docker image to pull, that is not the shape of this project. The repository you are looking at is the source for the service, not a client you run.

What you do instead is pick a scenario and request an instance. The README describes the flow as: read the scenario description, get an SSH shell through the browser to an ephemeral server, and try to solve the problem. A test then checks whether the issue is resolved.

If you want to run the platform itself rather than use the hosted one, the repository is an HCL-heavy infrastructure project. The top-level entries are documentation and images plus a scenarios directory; there is no quickstart in the README for standing up your own copy. Treat self-hosting as an infrastructure project, not a five-minute install. The README does point to a separate document for contributing scenarios, at docs.sadservers.com, under the heading about making money creating scenarios.

For a contributor adding a scenario, the relevant artifact is the scenarios directory at the repository root. The README does not spell out the file format there, so read the existing scenarios before writing a new one.

## SQLite as the Production Database, and When That Stops Working

SadServers runs on SQLite. The README does not present this as a compromise; it lays out explicit criteria for choosing SQLite in the first place. The application must not be so write-heavy that you hit lock errors, specifically SQLITE_BUSY. The cost of the projects depending on it should be under a few thousand dollars, on the reasoning that a managed PostgreSQL or MySQL instance with high availability and point-in-time recovery runs in the hundreds of dollars. And you must be comfortable with the downtime and possible data loss that come from not having automatic failover and recovery, recovering instead by copying files.

That is an unusually candid piece of documentation, and it doubles as the project's own statement of its limits. The moment SadServers becomes write-heavy enough to contend for the write lock, or valuable enough that losing the database is unacceptable, the design assumption breaks. The README even concedes that the Celery and RabbitMQ stack might be more than the job requires, noting that a simpler but still robust stack might do. Two self-aware trade-offs in one architecture section is more than most projects offer.

For anyone evaluating whether to fork or self-host, this is the section to read first. You are inheriting a single-writer database and a task queue that the author himself questions. Neither is a defect, but both are decisions you would have to re-make.

## Where SadServers Is the Wrong Tool

The scenario format has a real ceiling. Because each problem ends with a pass or fail test, the platform rewards reaching a working state within the time limit. The README says the author built SadServers partly out of frustration with interviews that felt like a game where you maximize arbitrary points, and the design tries to avoid that. But a timed, test-verified challenge still compresses troubleshooting into a single session. Long-horizon work such as capacity planning, incident review, or gradual degradation over weeks does not fit.

Time limits cut the other way too. An ephemeral server destroyed after the allotted time is the right default for practice and for interviews, and the beat scheduler enforces it. It is the wrong default if you want to leave a broken environment running while you read documentation, or if you want to come back to a half-solved problem tomorrow. The README mentions resumable VMs as a feature, but the core model is still a bounded session.

There is also the question of what the scenarios do not cover. The README lists Linux, Docker, and Kubernetes as areas, and says problems include common software like databases and web servers. That is a broad but not exhaustive map. If your troubleshooting happens mostly in Windows, in proprietary middleware, or in a cloud provider's managed services, the scenario library is unlikely to mirror your on-call reality.

Finally, the README does not document rollback, versioning of scenarios, or what happens to your progress if an instance fails to start. For a practice tool that is tolerable. For a hiring pipeline where a candidate's session is the assessment, an unexplained failure is a real problem, and the README is silent on how it is handled.

## SadServers Compared with a Static Practice Environment

The closest alternative is a self-managed lab: a local VM or a container you break yourself, or a static sandbox you keep around. The difference is in where the fault comes from. With a lab you build, you already know what you broke, which is a poor simulation of an incident. SadServers supplies the fault and withholds the answer, and the test tells you whether you actually fixed it rather than whether you think you did. That verification loop is the part a home lab does not give you for free.

The trade-off runs the other way for cost and control. A local VM is free, offline, and unlimited in time. SadServers is a hosted service with ephemeral instances and a time limit, and the README does not state pricing in the repository. If you are practicing on a train or behind a restrictive network, the hosted model is a liability.

A second alternative is a written interview exercise or a take-home debugging task. That gives an employer control over the exact problem and lets a candidate work at their own pace. What it loses is the environment: a take-home runs on the candidate's machine, with their tooling and their shell history, not on a server in a locked-down VPC. The README's command history logging exists precisely to recover some of that observability for the hiring case, which is a reasonable answer to the objection.

## Maintenance, Licensing and What the Repository Does Not Say

The repository is not archived, and its last push was on 2026-09-12. That is recent enough that the codebase is moving, and the README's inclusion of a roadmap and a collaboration section suggests the project expects outside contributors. There are no retrieved releases, so there is no versioned artifact to pin to; if you build on this, you are tracking the main branch.

The licence is the open question. The README has a Code License section, but the licence identifier is not available in the README excerpt, and the repository does not surface a standard licence file at the top level. Before you reuse any part of this project, particularly the scenarios, read that section in the README and confirm the terms yourself. Scenarios are content, and content licensing often differs from code licensing. Nothing here is legal advice; the point is that you cannot assume permissive terms.

Upgrade cost is hard to estimate from the README alone. The stack is ordinary and widely deployed (Django, Nginx, Gunicorn, Celery, RabbitMQ, SQLite, Boto3), which usually means upgrades are routine rather than exotic. The infrastructure is HCL, so changes to the AWS side are reviewable as code. The scenarios directory is the part most likely to need ongoing attention, since each scenario depends on software versions inside its image and on an external test that must keep passing.

## Conclusion

SadServers is worth adopting if you are an SRE, sysadmin, or DevOps engineer who wants to practice debugging on a real server rather than a quiz interface, or if you are hiring and want a troubleshooting exercise that does not depend on an interviewer improvising. It is the wrong tool if you need a fixed curriculum with graded difficulty, if you want to run the scenarios offline, or if you are looking for a certification path. Before you commit, verify the current pricing and free-tier limits on sadservers.com, confirm the licence terms for the scenarios directory, and run one scenario end to end to see whether the browser SSH session and the allotted time suit how you work.

## FAQ

### What is SadServers?

It is a SaaS for practicing Linux and DevOps troubleshooting on real Linux servers in a Capture-the-Flag format. You get a browser SSH session to an ephemeral server with a described fault and a test that checks whether you fixed it.

### Is SadServers free?

The README does not state pricing or free-tier limits; it only describes the service and links to sadservers.com. Check the site for current terms.

### Is SadServers good?

The README positions it for professional developers, sysadmins, DevOps engineers, and SREs, and says companies use it to run Linux troubleshooting interviews and internal training. Whether it suits you depends on whether timed, test-verified scenarios match how you want to practice.

### What is SadServers' pricing?

The repository does not document pricing. The README links to sadservers.com for the service itself and to docs.sadservers.com for creating scenarios.

## Sources

- [Issues](https://github.com/SadServers/sadservers/issues)
- [Project website](https://sadservers.com)
- [README](https://github.com/SadServers/sadservers/blob/main/README.md)
- [SadServers/sadservers on GitHub](https://github.com/SadServers/sadservers)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sadservers-sadservers