Getting started

Walis publishes self-contained binaries — no .NET on the target machine — for Windows (x64, arm64), macOS (Intel, Apple Silicon) and Linux (x64, arm64, 32-bit arm for Raspberry Pi, and musl/Alpine). Each archive contains the API with the admin UI built in, plus the runner.

macOS has a turnkey service installer, described below. On Windows and Linux, unpack the archive and run the binary under whatever init system you already use — there is nothing else to install.

Install as a macOS service

git clone https://github.com/walisayu/walis.git
cd walis
sudo ./deploy/install.sh --user "$(whoami)" --port 11120

That publishes a self-contained binary to /usr/local/walis/releases/<timestamp>, builds the admin UI into the same release, and registers two launch daemons:

Daemon	Runs as	Purpose
com.walisayu.walis	your account	the service itself
com.walisayu.walis-restarter	root	watches a trigger file and restarts the service

The service is a LaunchDaemon so it starts at boot, but the plist names a regular user — Walis runs arbitrary shell, and root is not the account you want that on.

Open http://127.0.0.1:11120.

This installer is the locked-down variant: the service listens on loopback and answers only to localhost names, on the assumption that a reverse proxy goes in front — see Deployment.

Or run it from source

dotnet run --project source/Walis.Api --no-launch-profile -- --urls http://127.0.0.1:11126
npm --prefix source/Walis.Admin run dev

First connection

Started from an archive or by install.sh, Walis answers plain HTTP from any machine:

./Walis.Api --urls http://0.0.0.0:11120

Open http://<this machine>:11120 and create the first administrator.

The form asks for a setup code, so that whoever opens the page first does not simply become the owner. Since 1.1 a production install asks for it on the machine itself as well: a reverse proxy on the same machine can make a remote browser look local. The server prints the code on its console when it starts and saves it as setup-code.txt in the data directory:

Installed as	Where to read the code
Started by hand	The console, or data/setup-code.txt next to the binary
install.sh --service	sudo cat /var/lib/walis-server/setup-code.txt, or journalctl -u walis-server

Type it in either case, with or without the dashes. It stays the same across restarts and is deleted as soon as the administrator exists.

From then on every request needs a sign-in.

Your first job

1. Jobs → New job
2. Give it a name and a working directory
3. Either write shell directly, or build a flow out of actions
4. Press Run

The log window shows each step separately: status, exit code, duration, and output that streams while the step is still running.

Already have a Jenkinsfile? Jobs → Import from Jenkins converts it into a draft job — steps, parameters, trigger and all — and tells you what it could not translate. See Import from Jenkins.

Before exposing it

Walis executes arbitrary shell, and its defaults favour a first run on a network you trust. Before it can be reached from anywhere else:

1. Add TLS, then require it. Put a reverse proxy in front — it must pass the Host header through and send X-Forwarded-Proto and X-Forwarded-For — or give Walis a certificate. Then set Security__RequireHttps=true: a remote request without TLS is refused and every cookie is marked Secure. A proxy on another machine must be listed in Security__TrustedProxies.
2. Name the hosts it answers to, for example AllowedHosts="walis.example.com;localhost". The default accepts any name.
3. Decide about build isolation. On Linux and Windows, and on remote runners, a build runs without a sandbox by default. Either let only people you trust edit jobs, or turn on Refuse to run without an isolation boundary in Settings → Build.
4. Consider one-time passwords in Settings → Security.

What each of these protects against is described in the security model.