Starting a homelab often feels backward. You want hands-on experience, but many guides assume you already picked a Linux distribution, found useful services, and learned safe deployment practices.
Three websites help with those early decisions:
- DistroSea offers temporary Linux sessions in a browser.
- selfh.st Apps organizes self-hosted software for browsing and comparison.
- Community Scripts provides Proxmox VE deployment helpers.
They cover three stages: choose an operating system, choose a useful service, and study deployment automation.
1. DistroSea: explore Linux before installing it
DistroSea runs temporary operating-system sessions through a browser. Its About page reports more than 50 operating systems and more than 500 versions.
You skip the ISO download, bootable USB, and local VM during the first comparison. Open a distribution, wait for a session, and inspect its desktop remotely.
Use DistroSea to compare:
- GNOME, KDE Plasma, Xfce, and other desktop environments
- menu and settings layouts
- default applications
- release editions
- package-management conventions
- general usability
This first pass helps answer simple questions. Does the desktop make sense to you? Are the settings easy to find? Which release edition deserves a local test?
What a browser session does not test
A hosted session does not represent your hardware performance, graphics support, Wi-Fi, disk installation, persistent storage, local networking, or long-term reliability. Browser latency and compression also change the experience.
Use this progression:
- Compare several candidates through DistroSea.
- Download the chosen ISO from the distribution’s official site.
- Verify its published checksum.
- Test it in a local VM.
- Check hardware compatibility and backups before installation.
DistroSea makes comparison faster. Local testing still decides whether a distribution fits your machine.
2. selfh.st Apps: find a service worth hosting
After building a server, you need a reason to use it. The selfh.st Apps directory collects self-hosted software and alternatives to popular hosted services.
The directory supports search and filters for category, tags, license, language, activity, age, stars, forks, and closed-source inclusion. Those controls help narrow a large catalog into a useful shortlist.
Common areas include:
- monitoring and dashboards
- file synchronization
- documents and notes
- photo and media libraries
- home automation
- networking and security
- development tools
- personal productivity
The directory helps you find names. The project’s official documentation decides whether a service belongs in your homelab.
Evaluate each project on its own
Before deployment, answer these questions:
- Is the software maintained?
- When did the latest release ship?
- Which license applies?
- How does authentication work?
- Does it support your identity provider?
- Which update process does it use?
- Which data needs backup?
- Does the project publish a container image or Compose example?
- What CPU, memory, and storage does it need?
- Does it require privileged access or host networking?
- Does the documentation include a restore process?
Open the official project site, documentation, release history, issue tracker, and security policy. A directory entry is a lead, not an installation plan.
Start with one problem
Avoid collecting applications for their own sake. Pick one need:
- monitor a server
- organize documents
- back up photos
- learn containers
- host a private dashboard
- replace one hosted service
Deploy one service. Document it, back it up, update it, and restore it before adding another. A small system you understand beats a large stack with no recovery plan.
3. Community Scripts: study Proxmox deployment helpers
Community Scripts is the community edition of Proxmox VE Helper-Scripts. It provides one-command installers for services, Linux containers, and virtual machines.
The collection covers hundreds of services across home automation, media, networking, monitoring, databases, security, and developer tools. Each page documents default resources and post-install information.
Default mode chooses common CPU, memory, storage, and network values. Advanced mode exposes more container, storage, networking, and application settings. Installed services also receive a post-install helper for updates, settings, logs, and basic troubleshooting.
This convenience crosses a serious trust boundary. The command runs from a root shell on the Proxmox host. Remote code with root access has permission to change packages, repositories, storage, networking, firewall rules, users, services, and guest configuration.
Never run an unfamiliar script blindly
Turn script review into a repeatable process.
Confirm the source
Start from the canonical Community Scripts site and follow its source link. Check the organization, recent changes, issue tracker, security policy, and activity around the specific script.
Do not copy installation commands from screenshots, comments, reposts, or similarly named projects.
Download before execution
Save the script instead of piping it directly into a root shell:
curl -fsSLo setup.sh 'https://example.invalid/path/to/script.sh'
The example URL is intentionally nonfunctional. Replace it with the exact canonical source for the selected application.
Read the complete chain
Open the downloaded file:
less setup.sh
Look for:
- other downloaded scripts or binaries
- root and
sudoassumptions - destructive disk or filesystem commands
- changes under
/etc - new package sources and signing keys
- firewall and network changes
- new users, groups, and permissions
- telemetry and external requests
- credential storage
- cleanup traps and rollback behavior
A short launcher often fetches more code. Follow every download before approving the first command.
Pin the reviewed version
A branch URL changes as maintainers update it. Prefer a release tag or exact commit when the project supports one. Record the source URL and commit in your deployment notes.
Calculate a checksum for the local file:
sha256sum setup.sh
The checksum records the exact file reviewed and executed. It does not prove safety.
Test away from important systems
Run the helper against a temporary Proxmox lab or disposable guest first. Take an appropriate backup or snapshot and verify the restore path.
A guest snapshot should not serve as the only backup. Keep recoverable copies of guest data and configuration outside the host receiving changes.
Read and record the result
Do not ignore warnings because a script is popular. Record the packages, services, users, ports, paths, credentials, and scheduled jobs created during installation.
After setup, compare the real system state with your notes. Test updates and restore procedures before moving important data into the service.
A practical first homelab path
Step 1: compare operating systems
Use DistroSea to compare distributions and desktop environments. Select one or two candidates.
Step 2: build a persistent test VM
Install the chosen system in a local hypervisor or Proxmox VM. Practice package updates, SSH, users, networking, storage, backups, and restores.
Step 3: choose one useful service
Browse selfh.st Apps and select software tied to a real need. Read its official deployment and recovery documentation.
Step 4: deploy a simple service manually
Manual installation teaches you where configuration, persistent data, logs, service units, and credentials live.
Step 5: compare automation
Read the matching Community Scripts helper. Identify each automated task and test the script on disposable infrastructure.
Step 6: document recovery
Record these details for every service:
- host and IP address
- ports and DNS names
- installation method
- configuration paths
- persistent data paths
- backup schedule and destination
- update procedure
- restore procedure
DistroSea helps you narrow the operating-system choice. selfh.st Apps helps you find software tied to a real need. Community Scripts shows how Proxmox deployments get automated.
Explore before installing. Research before deploying. Review before executing. Back up before changing. Verify after automation runs.