Gisila Panel

What it is

Gisila Panel is a self-hosted platform-as-a-service for one Linux server. You install it on an Ubuntu or Debian VPS, and it gives you a web UI and an HTTP API for teams, projects and apps. It also deploys those apps from git, an uploaded binary or a ZIP.

It does not use Docker or Kubernetes. Each app runs as a plain systemd service under its own Linux user, with systemd sandboxing, cgroups v2 limits, a seccomp filter and an AppArmor profile. Nginx reverse-proxies web apps and terminates TLS with Let’s Encrypt certificates. Because nothing runs per container, a 1 GB VPS can host many small apps.

The panel is built on the Gisila stack: the API uses Gisila, gisila_orm, gisila_doc and gisila_studio. You don’t need any of them to host your own apps, which can be written in any supported runtime.

Each app gets:

• Deployments from git (with optional push-to-deploy webhooks), a binary upload or a ZIP upload. The panel checks health after every deploy and can roll back instantly to a kept build.
• Env vars and secrets, encrypted at rest and written to a 0640 env file.
• Custom domains with Let’s Encrypt TLS.
• Cron jobs, a one-off command console, live runtime and build logs, CPU and memory metrics, and alert rules.

Superusers also manage node-wide infrastructure: runtime toolchains, PostgreSQL and MongoDB instances with backups, Redis and other managed services, S3-compatible object storage, a mail server, and the host firewall.

Install

You need Ubuntu 22.04+ or Debian 12+ (x64 or arm64), root access, and a PostgreSQL 16+ database and a Redis instance that the panel can reach. The installer doesn’t install those two for you.

curl -fsSL https://raw.githubusercontent.com/gumisofts/gisila_panel/main/infra/install-prebuilt.sh \
  | sudo env \
      DATABASE_URL='postgresql://gisila:<db-password>@127.0.0.1:5432/gisila_panel' \
      REDIS_URL='redis://:<redis-password>@127.0.0.1:6379' \
      PANEL_DOMAIN=panel.example.com \
      ISSUE_TLS=1 \
      bash

The full walkthrough is in Install on a VPS.

30-second example

With an API token (gsl_…) from Settings → API tokens, you can deploy a git-backed app from a script:

PANEL=https://panel.example.com
TOKEN=gsl_xxxxxxxxxxxxxxxx

# Queue a deployment of the app's configured branch
curl -sX POST "$PANEL/apps/42/deployments/" \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"sourceType": "git"}'

# Read the last 100 lines of its runtime log
curl -s "$PANEL/apps/42/runtime-logs/?lines=100" \
  -H "Authorization: Bearer $TOKEN"

When to use it

• You run several small backends (Dart, Go, Rust, Node, Bun, Python, Zig, static sites) and want them on one cheap VPS without paying container overhead for each.
• You want Heroku-style workflows (git deploys, env vars, domains, logs, rollbacks) on hardware you control.
• You host apps for several people or teams on one box and need real isolation between them: separate Linux users, filesystem sandboxing, resource limits and role-based access.
• You need non-HTTP services (game servers, MQTT, gRPC, queue workers) with the same sandboxing as web apps.

When not to use it

• You need more than one node, autoscaling or cross-host scheduling. The panel manages a single server. Use Kubernetes or a managed PaaS.
• Your apps depend on Docker images or docker compose stacks. Use Docker, Coolify or a container platform.
• You want someone else to run the servers. Use a managed PaaS.

See When to use the panel for a longer comparison.

Map of this section

ConceptsArchitecture, the resource model, deployments, security, networking and managed services.

GuidesInstall the panel, deploy apps, wire domains and databases, run workers, roll back, manage the firewall.

ReferenceEvery HTTP route, the app runtime contract, server configuration and the agent.

First deploy of a Gisila appShip a Gisila backend from git to HTTPS.