Server Setup
Slasha runs as a single binary on any Linux server. This page walks you through installing and configuring Slasha so you can begin deploying applications.
Requirements
- A Linux server
- systemd must be available (
systemctlmust exist) - Root access or a user with
sudo - Ports 22, 80, and 443 reachable from the internet
- A domain name you control, pointed at the server's IP
Recommended: one-command setup
Run this as root (or a sudo-capable user) on your server:
curl -fsSL https://slasha.com/setup.sh | bashThe script handles everything in one shot:
- Installs Docker (with Compose and Buildx plugins) if not present
- Installs OpenSSH and ufw if not present, then starts them
- Downloads and installs the Slasha binary to
/usr/local/bin/slasha - Creates a dedicated
slashasystem user and adds it to thedockergroup - Prompts for your platform domain and a JWT secret (auto-generated by default), then writes
/etc/slasha/.env - Registers and starts a systemd service (
slasha.service) so Slasha runs on boot - Configures ufw to allow ports 22, 80, and 443, deny everything else, and punch through the Docker bridge
- Configures fail2ban for SSH brute-force protection, if already installed
When the script finishes, it prints your domain URL and the DNS A record you need to point at the server. Once DNS propagates, visiting https://your-domain.com will open the fully functional Slasha web dashboard.
Slasha comes with a complete web-based user interface where you can manage your apps, view logs, scale services, and configure backups. If you prefer working from the terminal, the Slasha CLI is available as a powerful alternative that lets you control your server and manage resources directly from your local machine.
The first time you open the dashboard (or log in via the CLI), you will be prompted to create your initial administrator account.
After setup: useful commands
# check service status
sudo systemctl status slasha
# follow live logs
sudo journalctl -u slasha -f
# restart the service
sudo systemctl restart slashaConfiguration
Server configuration lives in /etc/slasha/.env. The setup script will prompt you for essential fields (like your platform domain and JWT secret) and write sensible defaults for the remaining variables; you can edit this file at any time and restart the service to apply changes.
| Variable | Required | Default | Description |
|---|---|---|---|
SLASHA_PLATFORM_DOMAIN | Yes | — | The root domain your Slasha instance runs on (e.g. slasha.example.com). Apps are reachable at <slug>.<SLASHA_PLATFORM_DOMAIN> by default. |
JWT_SECRET | Yes | — | Secret used to sign authentication tokens. Use a long random string. Changing this invalidates all existing sessions. |
SLASHA_ENV | No | development | Set to production on a live server. Affects logging behaviour. |
SLASHA_PORT | No | 3000 | Port the Slasha HTTP server listens on internally. The reverse proxy forwards traffic on 80/443 to this port. |
Data directories
All persistent data is written under a single directory:
| Path | Contents |
|---|---|
/var/lib/slasha/ (production) / ~/.slasha/ (dev) | Root data directory |
…/slasha.db | SQLite database (apps, deployments, users, services) |
…/repos/ | Bare Git repositories for each app |
…/logs/ | Deployment and service log files |
/etc/slasha/.env | Server configuration (production only) |
Upgrading
The easiest upgrade path is to re-run the install script — it detects the installed version and skips the download if already up to date:
curl -fsSL https://slasha.com/setup.sh | bashTo upgrade to a specific version, pass the SLASHA_VERSION environment variable:
SLASHA_VERSION=v0.0.0 curl -fsSL https://slasha.com/setup.sh | bashAfter the binary is replaced, restart the service:
sudo systemctl restart slashaOther installation methods
Docker
If you prefer not to use the automated host-based setup script, you can run Slasha inside a Docker container. We provide a Dockerfile and a docker-compose.yml file in the official GitHub repository. You can clone the repository on your server and build/run the Docker image from source.
- SSH Port: By default, the built-in SSH git server in the Docker container is configured to run on port
2222(instead of the standard port22) to avoid conflicts with your host's SSH server. - Manual Infrastructure Management: When using Docker, you are entirely responsible for setting up and managing your host system configuration, including the systemd unit files, firewall rules (e.g., UFW configuration), and security policies.