When to use the panel
What it is
Section titled “What it is”Gisila Panel sits between running services by hand and using a full container platform. It gives you a PaaS workflow (git deploys, env vars, domains, logs, rollback, teams) on one server you own, using systemd instead of containers.
When to use it
Section titled “When to use it”- Many small services on a small box. A systemd unit adds roughly nothing on top of your process, while each container brings a shim, an image filesystem and network namespaces. On a 1 GB VPS that difference decides whether you can run eight services or thirty.
- Compiled backends. Dart, Go, Rust and Zig binaries, or Bun, Node and Python apps, that run fine as a plain process.
- Several people or teams on one server, who need separate permissions and real isolation between their apps.
- Non-HTTP services that need the same sandbox and resource limits as web apps.
- You want to own the stack: open source, self-hosted, with an HTTP API and an MCP endpoint for automation.
When not to use it
Section titled “When not to use it”| You need | Use instead |
|---|---|
| More than one node, autoscaling, rolling deploys across replicas | Kubernetes, Nomad, or a managed PaaS |
| To deploy Docker images or compose stacks as they are | Docker / compose, Coolify, Dokku |
| Somebody else on call for the servers | A managed PaaS (Fly.io, Render, Railway, Heroku) |
| Kernel-level isolation between hostile tenants | Separate VMs per tenant |
| Windows or macOS hosts | Anything else: the panel needs Ubuntu 22.04+ or Debian 12+ |
How it works
Section titled “How it works”Compared with plain Docker
Section titled “Compared with plain Docker”| Gisila Panel | Docker on a VPS | |
|---|---|---|
| Per-app overhead | A systemd unit | Container runtime plus a shim per container |
| Isolation | Linux user, systemd sandbox, seccomp, AppArmor, cgroups | Namespaces, seccomp, cgroups |
| Build | On the host (git/ZIP) or upload a binary | Image builds, a registry |
| Deploy UI and API, domains, TLS, logs, rollback | Built in | Assemble them yourself |
| Reproducible images | No. Builds use the host’s installed toolchains | Yes |
Docker’s published ports bypass ufw, so if you also run Docker on a panel node, the panel’s firewall rules don’t cover those ports.
Compared with Kubernetes
Section titled “Compared with Kubernetes”Kubernetes schedules workloads across a cluster and needs a control plane that alone outweighs a small VPS. The panel schedules nothing: it runs everything on the host it’s installed on. If one server is enough, the panel is far less to operate. If it isn’t, the panel isn’t the tool.
Compared with a managed PaaS
Section titled “Compared with a managed PaaS”You get the same workflow without per-app pricing, and you keep root on the
machine. In exchange you operate the server: OS updates, backups of the panel
database and /etc/gisila/secret.key, panel upgrades with upgrade.sh, and
capacity planning.
Example
Section titled “Example”A good fit: a 2 GB VPS running a Gisila API (web), its
gisila_queue worker (process), a static frontend, a Postgres
instance and a Redis service from the panel, plus a staging copy of each in
another project.
A poor fit: a service that needs three replicas behind a load balancer with zero-downtime failover between machines.