Marketplace

Choose a Cloud VPS then select the desired template: the environment is installed automatically and accessible from your domain.

The Marketplace is a catalog of VPS templates: preconfigured open source applications that you deploy on your VPS in just a few clicks.

No. These are open source software programs that we offer as ready-to-deploy templates. You pay for the VPS that hosts them, not for the software.

The applications offered are open source and free. Your only cost is that of the Cloud VPS on which they run.

The catalog covers AI, automation, databases, CMS, deployment and more (143 solutions to date). It is enriched regularly.

Yes. Via the contact form, choose "Suggest a solution" and specify the open source application you would like as well as your use case.

An application's minimum requirements are stated for an empty server. But your already-installed applications are already consuming part of the RAM, CPU and disk: we therefore check the space actually AVAILABLE on your VPS (and not its total capacity) before launching a new installation, to avoid saturating the machine. If free space is insufficient, increase the resources from your client area (vCPU / RAM / disk options) then restart the installation — or uninstall an application you no longer need.

To guarantee an installation that works the first time, we check compatibility with what is already installed on your server. An application appears blocked in three cases: (1) "port conflict" — it needs the same network port as an application already present (two services cannot listen on the same port of a server); (2) "conflict" — it is a role that can only exist as a single instance, for example two reverse-proxies like Caddy and HAProxy that both want to manage ports 80/443; (3) "prerequisite" — it needs another application to be installed first. In each case, the reason is displayed under the application. To install it anyway: uninstall the conflicting application, install the prerequisite first, or use another VPS.

Gitea is a lightweight, open source Git platform written in Go. Self-hosting it gives you unlimited private repositories, built-in CI/CD (Gitea Actions), a package registry and fine-grained team permissions — all on a 2 GB RAM VPS, with no per-seat billing.

Gitea serves its web interface on port 3000 (proxied to 80/443 via Caddy or Nginx). Git over SSH is exposed on port 2222 to avoid conflicting with the VPS host SSH on port 22.

Yes. Enable Gitea Actions in your app.ini (`[actions] ENABLED = true`) and register an `act_runner` container on the same VPS. Gitea Actions is compatible with GitHub Actions YAML syntax, so most existing workflows run unchanged.

Use `git clone ssh://git@<your-domain>:2222/<user>/<repo>.git`. You can also add a Host block in `~/.ssh/config` to set Port 2222 transparently so that standard Git commands work without specifying the port.

Gitea runs comfortably on a VPS with 1 vCPU and 2 GB RAM for teams up to 20 users. Add more RAM if you enable local Gitea Actions runners that compile code. Plan at least 20 GB of SSD storage per repository volume.

PocketBase is an open-source backend-as-a-service (BaaS) written in Go. It bundles an embedded SQLite database, a realtime REST and WebSocket API, built-in authentication (email/password, OAuth2, OTP) and a web admin dashboard in a single binary — no external database server or configuration files required.

PocketBase runs on 512 MB RAM for light workloads. A 1–2 GB VPS handles thousands of daily active users comfortably. Scale up only if you process very large files or run compute-intensive background jobs alongside it.

PocketBase is far lighter (one binary vs 10+ Docker services for Supabase) and has a fixed VPS cost with no per-read/per-write billing. Firebase and Supabase are better for infinite cloud scale; PocketBase is better for cost-predictable apps under ~1 M daily requests.

PocketBase supports Google, GitHub, GitLab, Apple, Twitter/X, Facebook, Microsoft, Spotify, Kakao, Twitch and more. Enable them in the admin dashboard under Settings → Auth Providers by pasting your OAuth2 client ID and secret.

All data lives in the `/pb/pb_data` Docker volume — one SQLite file plus uploaded files. Back up this volume with `docker run --rm -v pocketbase:/data alpine tar -czf - /data`. PocketBase also exposes a built-in backup endpoint accessible from the admin dashboard.

Yes. PocketBase supports JavaScript hooks since v0.17: run code before or after record create, update, delete, or authentication events. For advanced use cases, embed PocketBase as a Go library and add your own HTTP handlers or background jobs.

Vaultwarden is an open-source, unofficial implementation of the Bitwarden server written in Rust. It is 100% compatible with all official Bitwarden clients (browser extensions, iOS, Android, desktop, CLI) and uses under 50 MB RAM — making it ideal for self-hosting on a small VPS.

Yes. Official Bitwarden clients refuse to connect to a server without a valid TLS certificate. You need a domain name and a reverse proxy (Caddy, Nginx, or Traefik) with a Let's Encrypt certificate. Caddy makes this a one-liner — it provisions and renews the cert automatically from your Caddyfile.

Vaultwarden idles under 50 MB RAM. A 512 MB VPS is sufficient for personal use or a small team; 1 GB is comfortable for an organization with 20–50 users. It runs easily alongside other services without impacting performance.

Yes. Export your vault from Bitwarden.com (Settings → Export Vault → JSON format) and import it in Vaultwarden's web vault under Tools → Import Data. The process takes under two minutes and preserves all passwords, folders, notes, and identities.

Set the environment variable `SIGNUPS_ALLOWED=false` on the container and restart it. New sign-ups will be rejected. You can still invite specific users via the admin panel, which you enable with the `ADMIN_TOKEN` environment variable.

All data lives in the `/data` Docker volume: one SQLite file plus file attachments. Run `docker run --rm -v vaultwarden:/data -v /backup:/out busybox tar czf /out/vaultwarden-backup.tar.gz /data` to create a snapshot. Schedule this in cron for automated daily backups.

Beszel is a lightweight open-source (MIT) server monitoring hub. You deploy one hub and install small agents on each server you want to track. The hub aggregates real-time CPU, RAM, disk, bandwidth and Docker container metrics across all your servers in a single PocketBase-backed dashboard.

The hub idles under 50 MB RAM and fits comfortably on a 512 MB VPS alongside other services. Agents are even lighter — a few MB each. You can monitor 20+ servers without the hub using more than ~100 MB RAM.

No. Beszel agents establish outbound connections to the hub — monitored servers do not need any inbound ports opened. You only need port 8090 (or your HTTPS proxy port) accessible on the hub server itself.

Uptime Kuma is built for availability checks: is a URL or TCP port up or down? Beszel is built for resource monitoring: CPU, RAM, disk, bandwidth and Docker stats per server. They complement each other — use Uptime Kuma for external blackbox probes and Beszel for internal metrics across your fleet.

Yes. Mount `/var/run/docker.sock` when running the agent container and Beszel automatically discovers and tracks all Docker containers on that host — CPU, RAM and network per container, with no extra exporter required.

Beszel supports email, Telegram, Slack, Discord, ntfy, PagerDuty and Pushover via its built-in notification settings. Define a threshold on any metric (e.g. disk > 80%) and Beszel fires the alert when the threshold is crossed and again when it clears.

Twenty is an open-source CRM (AGPL-3.0) built as a self-hosted alternative to Salesforce and HubSpot. It offers customisable objects and fields, kanban and list views, a GraphQL + REST API, built-in notes and tasks, and a background worker for automations and webhooks. As of v2.1.0 it is production-ready for single-tenant self-hosted deployments.

The full Twenty stack (server + worker + PostgreSQL + Redis) idles around 1.2 GB RAM. Plan for 2 GB minimum and 4 GB recommended to give PostgreSQL room under concurrent queries. The server itself uses roughly 300–400 MB at idle.

Yes — Twenty is fully open source under AGPL-3.0. Self-hosting on your own VPS is free. There is no per-seat fee, no usage billing and no features gated behind a paid plan on the self-hosted edition. You only pay for the VPS.

HubSpot and Salesforce are cloud SaaS products with per-seat billing and your data stored on their infrastructure. Twenty is self-hosted: all data stays on your server, the cost is a flat VPS fee, and you can extend the schema, API and automations without vendor approval or marketplace restrictions.

Yes — every object in Twenty (contacts, companies, deals, and any custom object you define) is accessible via a fully documented GraphQL API and a REST API. Webhooks fire on any record event. The API is the primary integration surface, not an afterthought.

Yes. Twenty supports CSV import from workspace settings → Import. Export your contacts and companies as a CSV from HubSpot, Pipedrive or any legacy CRM, then import them into the matching Twenty object. More complex migrations (deals with activity history) may need a short API script.

Qdrant is an open-source vector database written in Rust. It stores document chunks as embedding vectors and retrieves the most similar ones in milliseconds. RAG (Retrieval-Augmented Generation) uses this to inject relevant context into each LLM call — so your AI answers from facts instead of hallucinating. A relational database or full-text index cannot match Qdrant's speed or accuracy at this task.

Qdrant idles at around 100–200 MB of RAM. The practical limit is your index size: 1 million 1536-dimensional float32 vectors take roughly 6 GB unquantised, or ~1.5 GB with scalar quantisation (int8). For most small-to-medium RAG projects, a 4 GB VPS is the comfortable starting point.

Any model that produces fixed-size float vectors. Popular self-hosted choices via Ollama: mxbai-embed-large (1024 dims), nomic-embed-text (768 dims). Via API: OpenAI text-embedding-3-small (1536 dims), Cohere Embed. LangChain, LlamaIndex, Haystack, and the official Qdrant SDKs (Python, TypeScript, Go, Rust) all have native connectors.

Yes. Both are single-container deployments with no port conflict (Ollama on 11434, Qdrant on 6333/6334). A 4 GB RAM VPS comfortably runs both with a 7B Q4 model loaded — giving you a fully self-contained, air-gapped RAG stack: embed with Ollama, retrieve with Qdrant, generate with Ollama, no external API needed.

Yes. Qdrant is the leading self-hosted alternative to Pinecone. It matches or exceeds Pinecone on benchmark latency and recall, supports the same embedding model ecosystem, and costs a flat VPS fee instead of per-vector and per-query billing. The trade-off: you manage the infrastructure yourself.

Restart the container with the QDRANT__SERVICE__API_KEY environment variable set to a strong random string. All REST and gRPC requests must then include the `api-key` header. Place Qdrant behind Caddy or Nginx for HTTPS. Never expose port 6333 to the internet without authentication.

Infisical is an open-source secrets manager (MIT, 27.6k stars) — a self-hosted alternative to Doppler and HashiCorp Vault. It centralises API keys, database passwords and certificates in one vault, synced automatically to your apps and CI pipelines via SDKs and native integrations. Self-hosting keeps your most sensitive credentials on your own infrastructure with full audit logs, at a flat VPS cost instead of per-developer SaaS billing.

The Infisical stack (app + PostgreSQL 14 + Redis) idles around 600–800 MB of RAM and peaks above 1 GB under concurrent API requests from multiple apps. Plan for a VPS with at least 2 GB RAM (4 GB recommended for teams with several services pulling secrets simultaneously).

Yes. Infisical has first-class CI/CD integrations: GitHub Actions (official action in the marketplace), GitLab CI (native variables sync), CircleCI and Jenkins. You add a service token as a CI secret, then the integration injects the right environment's secrets directly into each pipeline run — no .env files, no manual rotation.

Yes. Install the Infisical SDK (`npm install @infisical/sdk` or `pip install infisical-python`) and fetch secrets at startup. Alternatively use the CLI wrapper: `infisical run -- node server.js` injects secrets as environment variables so your app reads them via `process.env` — no SDK integration required, and no secrets ever touch the filesystem.

Yes. Infisical encrypts every secret value at rest using AES-256-GCM with an `ENCRYPTION_KEY` you generate and control. In transit, all communication is HTTPS. Access is governed by role-based policies, service tokens and machine identities with the principle of least privilege. Every read and write is recorded in the audit log. The MIT core includes all these security features — no paid tier required.

They solve different problems: Vaultwarden is a personal and team password manager (Bitwarden-compatible — human login credentials, browser extensions, mobile apps). Infisical is a secrets manager for machines and code (API keys, database URIs, tokens — consumed programmatically by apps and CI/CD pipelines via SDKs or the CLI). Most teams use both: Vaultwarden for human credentials, Infisical for application secrets.

Dockge is an open-source (MIT) visual manager for Docker Compose stacks, created by Louis Lam — the same developer behind Uptime Kuma. It lets you create, edit, start, stop and monitor all your multi-container applications from a clean web UI on port 5001, without SSH or command-line. It stores every stack as a standard `compose.yaml` file under `/opt/stacks` on your host.

Dockge idles under 150 MB RAM and fits on any VPS without impacting the other services running on it. It is built on Node.js with a SQLite database — there are no external databases or caches to provision. A 512 MB VPS can run Dockge comfortably alongside several managed stacks.

Yes. Place your existing `compose.yaml` files inside subdirectories under `/opt/stacks` (e.g. `/opt/stacks/n8n/compose.yaml`) and Dockge will discover and display them automatically on next load. The file path convention is `<stacks-dir>/<stack-name>/compose.yaml` — any stack already following that layout appears in the UI without any import step.

They solve different scopes: Dockge is a pure Compose manager — it lets you create and manage stacks on the same server it runs on. Coolify and Dokploy are full PaaS platforms with Git integration, automatic SSL, environment promotion and multi-server deployments. Use Dockge when you want a lightweight UI for your hand-crafted stacks; use Coolify or Dokploy when you want git-push-to-deploy and automated SSL out of the box.

The built-in terminal console was disabled by default in v1.5.0 following a security advisory (GHSA-7vx4-hf96-mqq6). The rest of Dockge — stack management, log streaming, status dashboard — is fully functional without the console. Do not enable it on a public-facing instance. If you need shell access to containers, use a dedicated SSH session instead.

Open the stack in the Dockge UI, click Update, then Start. Dockge runs `docker compose pull` followed by `docker compose up -d` under the hood. To update Dockge itself, edit its own `compose.yaml` (under `/opt/dockge` or wherever you installed it), change the image tag if needed, and run `docker compose up -d` from the terminal — or use another Dockge instance to manage it.

Authelia is an open-source (Apache 2.0) authentication and authorization gateway. It sits in front of your apps as a forward-auth endpoint on your reverse proxy (Nginx, Caddy, Traefik). Every request is checked against your policy: unauthenticated users are redirected to the Authelia login portal, where you can enforce a password, TOTP, passkeys or any combination. Apps themselves need no changes — Authelia protects them at the infrastructure level.

Yes. Authelia's session cookies must be scoped to a domain (`Domain=.yourdomain.com`), and OIDC callbacks and Let's Encrypt certificates require a publicly resolvable FQDN with HTTPS. Authelia cannot function correctly behind a plain IP address. When you deploy through ServOrbit, point an A record to your VPS and enter the domain during setup — the reverse proxy and TLS certificate are configured automatically.

Authelia itself idles under 30 MB RAM. Add approximately 20 MB for the Redis session store. Total: under 60 MB for the full authentication stack. A 512 MB VPS is sufficient for personal use; 1 GB is comfortable for a team of 20 or more users.

Yes. Authelia is a certified OpenID Connect (OIDC) provider. Register each app as an OIDC client in `configuration.yml` — give it a client ID, a secret and a redirect URI. Then configure the app to use Authelia as its identity provider. Users authenticate once at your auth portal and are silently forwarded to every connected app without re-entering credentials.

Authelia supports TOTP (any authenticator app: Google Authenticator, Ente Auth, Aegis, Bitwarden Authenticator), WebAuthn/Passkeys (Touch ID, Face ID, YubiKey, any FIDO2 hardware key), and Duo push notifications. Users can register multiple methods and choose at login time. MFA is enforced per-domain, per-group or globally depending on your access control rules.

Actual Budget is an open-source (MIT), local-first personal finance application built on zero-based (envelope) budgeting. It is a self-hosted alternative to YNAB — you run a lightweight Node.js server on your own VPS and sync your budget to any device through end-to-end encryption. Your financial data never leaves your infrastructure.

The budgeting methodology is identical: assign every dollar to a named envelope (category) before spending it. The differences: Actual is MIT-licensed with no subscription fee, your data stays on your own server, and the source code is fully auditable on GitHub. YNAB has a more polished native mobile app; Actual has a fast PWA and an active open-source community.

The Node.js server idles under 80 MB RAM. A 1 GB VPS is more than sufficient for multiple simultaneous users. Actual Budget is one of the most resource-efficient self-hosted finance tools available.

Yes, via two optional integrations: GoCardless for European banks (open banking API, no credential sharing) and SimpleFIN for North American banks. If your bank is not supported, you can import OFX, QFX, QIF or CSV files exported from your online banking portal. Manual transaction logging also works well for cash-flow awareness.

Yes. All data is stored in an SQLite file on your VPS and synced between devices using end-to-end encryption — the server only handles ciphertext and never reads your transactions or balances. No third-party service has access to your financial records.

Yes. Actual supports direct import from YNAB 4 (local export) and nYNAB (web export). Your categories, accounts, budgeted amounts and transaction history all carry over. The migration takes about five minutes from within the Actual Budget settings screen.

Umami is an open-source web analytics tool (MIT licence) that measures your audience without cookies or personal data collection. Unlike Google Analytics 4, Umami requires no cookie consent banner (no cookies → no GDPR obligation), the tracking script weighs under 2 KB and is served first-party from your domain. Your data stays on your VPS and never passes through a third-party server.

There is no limit. A single Umami instance can track an unlimited number of websites. Each site gets its own tracking ID and API keys, allowing per-site access control — useful for agencies managing multiple clients. Resource usage scales with event volume, but 1–2 GB of RAM is sufficient for dozens of moderate-traffic sites.

By default, the script is served at `/script.js` on your domain. Most ad-blockers do not target generic file names on first-party domains, so Umami typically gets through where Google Analytics and Plausible are blocked. For extra protection, set the `TRACKER_SCRIPT_NAME` environment variable in your Docker Compose file to rename the script to something neutral (e.g. `u`), making it virtually invisible to filter lists.

Yes. Umami provides a simple JavaScript event API: call `umami.track(eventName, data)` anywhere in your code, e.g. `umami.track('signup_click', { plan: 'pro' })`. Events appear in the dashboard under the Events tab. No tag manager, no Google GTM — just a function call and your own data on your own server.

Yes. The open-source version of Umami (MIT licence) is completely free with no feature limitations. Umami also offers a paid managed cloud plan at umami.is, but on ServOrbit you only pay for the VPS — Umami itself costs nothing.

DocuSeal is an open-source electronic signature platform (AGPL-3.0, 17 k+ stars, v3.1.4) that lets you create PDF templates, send signing requests to multiple parties and collect legally binding digital signatures — entirely on your own server. It is a self-hosted alternative to DocuSign, Adobe Acrobat Sign and HelloSign.

No. DocuSeal uses SQLite by default — the database is a single file stored at `/data/db.sqlite3` inside the container. No PostgreSQL, MySQL or Redis server is needed. The volume mounted at `/data` persists all documents and the database across container restarts.

DocuSeal idles under 256 MB of RAM. A 1 GB VPS is comfortable for teams processing dozens of documents per month. For high volume or multiple simultaneous signing sessions, a 2 GB plan is recommended.

No. Each signer receives a unique link (via email if SMTP is configured, or shared manually). They open the link in any browser, fill in their fields and submit — no registration, no app download required.

DocuSeal generates an audit trail containing the signer's email, IP address and timestamp for each signature, plus a completion certificate. This satisfies the evidence requirements for simple electronic signatures under eIDAS (EU) and equivalent laws in many countries. For everyday NDAs, contracts and consent forms, DocuSeal's audit trail is sufficient.

Yes. Without SMTP, DocuSeal is fully functional — you copy signing links from the Submissions page and share them manually (via Slack, WhatsApp or email). SMTP is recommended to automate invitations, reminders and completion notifications, but is not required to send and collect signatures.

Changedetection.io is an open-source tool (Apache 2.0) that monitors any website and alerts you the moment a page changes — prices, stock levels, tenders, official publications. It runs on your VPS with no per-check fees.

Yes, via an optional Playwright/Chromium sidecar container. Changedetection.io connects to it for full browser rendering — ideal for dynamic stock counters, SPAs and checkout pages.

Over 80 channels via the Apprise library: email (SMTP), Telegram, Slack, Discord, ntfy, Gotify, Matrix, custom webhooks and many more. You can configure multiple channels per monitored URL.

Yes. Use a CSS selector (e.g. `.price`), an XPath expression or a keyword trigger (alert only when the page contains or stops containing a given text). Filters eliminate noise from menus, ads and timestamps that change on every load.

The main container idles under 256 MB. A 1 GB VPS comfortably monitors hundreds of URLs. With the Playwright/Chromium sidecar for JavaScript pages, plan for 2 GB total.

Yes. Changedetection.io is open-source under the Apache 2.0 licence — no URL limits, no per-check fees, no mandatory cloud account. You pay only for the VPS that hosts it.

Memos is a lightweight open-source notes app (MIT): capture ideas, run a personal journal or share notes with your team from your VPS. ~20 MB Docker image, under 128 MB RAM, SQLite by default.

Memos idles under 128 MB RAM with SQLite. Its ~20 MB Docker image is one of the lightest in the catalogue — it co-locates comfortably with other apps on a 1 GB VPS without noticeable impact.

Yes. Memos renders Markdown live in the timeline view: bold, italic, code blocks, checkboxes, links and inline images — all rendered as you type. Pasted screenshots are also uploaded and embedded directly.

Yes. Each note can be toggled to public via the share icon — it gets a shareable link accessible without login. The rest of the instance stays private. You can also make the whole instance publicly browsable for a personal micro-blog.

Yes. Memos exposes a RESTful API at /api/v1/ with token authentication. You can post notes from scripts, CI pipelines, cron jobs or a Telegram bot — useful for automated standup logs or captures from other tools.

Yes. Memos is MIT-licensed — free to use, modify and self-host. No subscription, no telemetry, no cloud account required. You pay only for the VPS that runs it.

Chatwoot is an open-source omnichannel customer support platform (MIT, 34 k+ stars, v4.16.0) that centralises live chat, email, WhatsApp, Telegram, Facebook Messenger and Twitter/X DMs into one shared inbox. Self-hosted on your VPS, it is an alternative to Intercom and Zendesk with no per-agent fees.

Yes. Chatwoot integrates with the WhatsApp Business Cloud API (Meta), Twilio WhatsApp and the Telegram Bot API. You connect each channel from the Settings → Inboxes panel. Messages from these channels appear in the shared inbox alongside live chat and email.

Create a Website-type inbox in Settings → Inboxes. Chatwoot generates a two-line JavaScript snippet. Paste it into your site's <head>: a customisable chat bubble appears instantly for your visitors. Colour, greeting message and team name are configurable from the dashboard.

Chatwoot runs four Docker containers (Rails + Sidekiq + PostgreSQL + Redis) that idle around 1.2 GB RAM. A 2 GB RAM VPS is the minimum for production; 4 GB is recommended for teams over 10 agents or with high conversation volume.

Yes. Chatwoot requires a valid FRONTEND_URL (FQDN over HTTPS) for OAuth redirects, email links and the live-chat widget script URL to work correctly. Without a domain, these features (email integrations, notifications, widget) will not work reliably.

Yes. Chatwoot Community Edition is MIT-licensed open-source software — free to install and self-host with unlimited agents. You pay only for the VPS that hosts it, not the platform. Enterprise features (SSO, advanced audit logs, custom roles) are available in the paid cloud plans.

Vikunja is a self-hosted open-source task and project management platform (AGPL-3.0, 24 k+ stars, v2.4.0). It provides list, Kanban and Gantt views with dependencies, recurring tasks, CalDAV sync and a full REST API — a self-hosted alternative to Todoist, TickTick and Asana without recurring fees.

Vikunja idles under 256 MB RAM using SQLite as the default store. The Docker image is approximately 80 MB. A 512 MB VPS can run Vikunja alongside a reverse proxy without any overhead — a 1 GB plan gives comfortable headroom.

Yes. Vikunja supports list view, Kanban boards with drag-and-drop and Gantt chart view with start/end dates and task dependencies. You can switch views per project without migrating any data.

Yes. Vikunja exposes a CalDAV/WebDAV endpoint at `/dav/`. Any CalDAV-compatible client — Thunderbird, DAVx⁵, Apple Reminders — can connect with your Vikunja credentials and sync tasks natively.

Yes. Vikunja ships a full REST API documented with a Swagger spec at `/api/v1/docs`. You can create, update and close tasks via HTTP with an API token — useful for CI pipelines that auto-close tasks on successful deploy.

Yes. Vikunja is AGPL-3.0 open-source software — free to use and self-host. There are no per-seat fees, no subscription plans and no telemetry. You pay only for the VPS that runs it.

Paperless-ngx is a self-hosted, open-source document management system (DMS/GED) under AGPL-3.0 (43 k+ stars). It scans, OCRs via Tesseract (French, English, Arabic), indexes full-text and auto-files documents by correspondent, type and tags — all on your VPS, with no data sent to a third-party cloud.

Yes. The Docker image bundles Tesseract with full language packs. The variable `PAPERLESS_OCR_LANGUAGE=fra+eng` — preconfigured in the ServOrbit recipe — enables simultaneous OCR in French, English and Arabic on every document. Mixed-language documents are correctly processed in both languages.

The full stack (Django web server + PostgreSQL 16 + Redis 7) idles at around 400–512 MB of RAM. A 2 GB VPS is recommended for normal use; 4 GB for large archives (100 k+ documents) or intensive concurrent OCR.

They are complementary tools with different use cases. Stirling-PDF is a PDF toolbox (50+ operations: merge, split, compress, convert, sign…) — you use it to process PDF files on demand. Paperless-ngx is an archival DMS: you file documents once and it indexes, classifies and makes them searchable forever. Both work great together.

Yes. Paperless-ngx exposes a full REST API documented at `/api/` (Swagger). You can list, search, download, upload and delete documents via HTTP. In n8n, a single HTTP Request node is enough to trigger ingestion of an email attachment or a PDF generated by a CI pipeline.

Yes. Paperless-ngx is AGPL-3.0 open-source software — free to use, modify and self-host. No per-document fees, no storage limits, no subscription. You pay only for the ServOrbit VPS running the stack.

NocoBase is an open-source no-code/low-code platform (Apache-2.0, 23 k+ stars) that lets you build internal tools, CRM, approval workflows and client portals without writing frontend code. The principle: define collections (entities with fields, relations and permissions), then compose a UI with drag-and-drop blocks (tables, forms, Kanban, charts). Each collection automatically generates a REST API. On ServOrbit, NocoBase installs as two Docker containers (app + PostgreSQL 16) on a 2 GB RAM VPS.

NocoDB turns any database into a collaborative spreadsheet-style grid — the focus is on viewing and editing existing data quickly in grid, gallery or simple Kanban layouts. NocoBase is data-model-first: you design entities, relations, field types and permissions, then compose complex UIs with blocks (multi-step forms, workflows, dashboards). NocoDB excels at quick ad-hoc data browsing; NocoBase is built for structured business applications with approval chains, granular roles and automations. Both are available in the ServOrbit marketplace.

Yes. NocoBase is well-suited for building a custom CRM: create Contacts, Companies, Opportunities and Activities collections with relations between them. Add a Kanban view for the sales pipeline, a lead capture form and different permissions per team (sales reps see their own opportunities, managers see all). The workflow engine can send automatic emails when an opportunity changes status or schedule follow-up reminders. Everything stays on your VPS, exportable via CSV or REST API at any time.

No. NocoBase works without a domain name on `http://your-vps-ip:13000` for internal or testing use. If you want to expose your instance on the internet with HTTPS, point a subdomain to your VPS and ServOrbit will automatically set up the nginx reverse proxy + Let's Encrypt certificate during Marketplace deployment. For strictly internal use (team connected via VPN or local network), port 13000 without a domain is sufficient.

Yes. NocoBase has a built-in plugin manager (Settings → Plugin Manager). It offers 80+ official plugins: Kanban, Gantt and calendar views, chart blocks, map blocks, file manager, visual workflows, Excel import/export, LDAP/SSO integrations (Enterprise), audit logs and more. Plugins are activatable on the fly without restarting the server. The plugin API is public, allowing your team to develop custom extensions if needed.

Yes. NocoBase is Apache-2.0 open-source software — free to use, modify and self-host with no per-seat fees, no collection limits and no telemetry. A paid Enterprise plan exists for teams needing premium plugins (SAML SSO, advanced audit logs, white-label), but the Community edition covers the essentials for the vast majority of use cases. You pay only for the ServOrbit VPS that runs the stack.

Glance is a lightweight self-hosted dashboard (AGPL-3.0, ~35 k ⭐, Go). It consolidates Hacker News, RSS feeds, live VPS stats (CPU, RAM, disk) and Docker container status on one page — a single YAML config file, no database, under 25 MB RAM.

No. Glance works fully on a plain IP address and port (e.g. http://95.x.x.x:8080). A domain and HTTPS are not required, but recommended for session-cookie security. You can add a Caddy reverse proxy in front of Glance at any time.

Edit /data/glance.yml inside the Docker volume on your VPS. Each widget is a YAML block in a page's columns section. For example, add `- type: rss` with feed URLs, or `- type: docker-containers` to monitor containers. Restart with `docker compose restart glance`. The official docs list 30+ widget types.

No. Glance ships with built-in auth (username/password). Any visitor is redirected to a login page. You can add multiple users in the auth.users section of glance.yml, or place Glance behind a VPN for extra protection.

Yes. Add `- type: docker-containers` to a column in glance.yml. The ServOrbit provisioning playbook already mounts /var/run/docker.sock read-only inside the Glance container. You will see the name, image and running status of every active container on the VPS.

Glance idles under 25 MB RAM even with multiple widgets active. It is a static Go binary with no database or external process. You can run it on a 512 MB VPS alongside other services (Dozzle, Uptime Kuma) without exhausting memory.

Komodo is an open-source GitOps platform (GPL-3.0) for managing Docker stacks and deployment pipelines across multiple servers from a single dashboard. It uses a Core / Periphery architecture: the Core centralises management, and lightweight Periphery agents are installed on each server to control.

Dockge and Portainer are single-server Docker management UIs. Komodo is built for multi-server fleets: one Core manages unlimited servers via Periphery agents. It also adds GitOps pipelines, automated Procedures and Docker Swarm support — features absent from both tools.

Yes, a domain name (or subdomain) is required because KOMODO_HOST must point to the public HTTPS URL of your Core. This URL is used for HMAC webhook signature validation and OAuth callbacks. The ServOrbit playbook automatically configures TLS via certbot during deployment.

Install the Periphery agent on each new server with the Docker command provided in the Komodo documentation (`docker run -d --restart=unless-stopped --network host -v /var/run/docker.sock:/var/run/docker.sock ghcr.io/moghtech/komodo-periphery:2`), then add it in the Komodo UI via Servers → Add Server, entering its IP and port 8120.

Yes. Configure a webhook in your GitHub repository pointing to `https://your-domain.com/api/webhook/komodo`. In Komodo, create a Procedure with your deployment steps (pull image, restart stack, notification) and link it to the webhook. Komodo validates the HMAC signature before executing anything.

The Komodo Core binary (Rust) idles under 256 MB RAM. The FerretDB + PostgreSQL database adds approximately 200–300 MB. A 1 GB RAM VPS is sufficient for the control plane alone. Periphery agents are even lighter — under 50 MB each.

Authelia is a lightweight forward-auth proxy that adds MFA in front of your apps without modifying them — it has no user management console. Authentik is a full Identity Provider (IdP) with its own directory, admin console, SSO via OIDC/SAML/LDAP and a visual flow editor. Use Authelia to quickly protect existing apps; use Authentik when you need a real IdP with user lifecycle management.

The server and worker containers idle at around 300–400 MB combined. PostgreSQL 16 adds ~150 MB. A 1 GB VPS is the absolute minimum; 2 GB is recommended for comfortable use. Authentik dropped its Redis dependency in v2025.10, so no additional cache layer needs to be provisioned.

Yes. OIDC callbacks, SAML assertions and session cookies all require HTTPS with a valid, publicly resolvable FQDN. ServOrbit automatically provisions a TLS certificate via Let's Encrypt as long as your domain's DNS A record points to the VPS.

Any app that supports OIDC/OAuth2 or SAML 2.0. Examples from the ServOrbit marketplace: Gitea, Nextcloud, Mattermost, Docmost, Grafana, Dockge and Metabase. Authentik ships pre-built integrations for dozens of popular apps and allows creating custom OIDC/SAML providers for any other app.

Yes. Authentik supports LDAP source sync — pull users from Active Directory or OpenLDAP with scheduled synchronisation. For CSV imports, use the REST API or the admin-console bulk-import tool. Users can also self-register via customisable enrollment flows.

Absolutely. Authentik is widely used in homelabs and teams of 2–20 users. The Community Edition (Apache 2.0) is fully featured for these use cases. The Enterprise edition adds advanced RBAC, support SLA and features for larger organisations, but is entirely optional.

Penpot is an open-source (MPL-2.0) self-hostable collaborative design tool, while Figma is a proprietary SaaS. The core technical difference: Penpot uses standard SVG as its native file format, whereas Figma uses a proprietary binary format. In practice, your Penpot files are readable by any vector editor, exportable and versionable in Git. Functionally, Penpot offers vector design, components, prototyping and developer handoff — the same core features as Figma.

The absolute minimum is 2 GB RAM — the stack starts, but exporting complex files (PDF, high-resolution PNG) can saturate the `penpot-exporter` container. The recommended configuration for production use is 4 GB RAM with 2 vCPU. On a 4 GB ServOrbit VPS, the Penpot stack at idle consumes around 800 MB, leaving headroom for other services. For teams with more than 10 simultaneous active users, plan for 8 GB.

Yes. Penpot natively imports `.fig` files exported from Figma. In a Penpot project, use Import → Figma file to select your export. Frames, components, styles and grids are converted to Penpot elements. Expect minor losses on Figma-specific features (certain plugins, advanced effects), but the overall structure, layers and style properties are preserved. Penpot also imports its native `.penpot` format and SVG files.

Yes. Penpot is 100% open-source (MPL-2.0) and the self-hosted version has no limits on users, projects or files. There is no paid 'Team' or 'Enterprise' plan for self-hosting — you pay only for infrastructure (your ServOrbit VPS). Real-time collaboration, shared libraries and developer handoff are all available with zero licensing cost.

Yes, for production use with multiple users. Penpot requires HTTPS for secure session cookies and the WebSockets that power real-time collaboration. Without an HTTPS domain, the app runs in `disable-secure-session-cookies` mode, which is acceptable for local testing but not for a team. When deploying via the ServOrbit marketplace, the provisioner automatically configures the Nginx reverse proxy and Let's Encrypt certificate from the domain you provided.

Yes. Penpot supports OIDC (OpenID Connect) and LDAP authentication. You can connect it to Authentik (available on the ServOrbit marketplace) to centralise authentication across your entire self-hosted stack. Configuration is done via the `PENPOT_FLAGS` environment variable (enable `enable-oidc`) and OIDC provider parameters. Users then log in via your central IdP — SSO, MFA, passkeys — without managing separate accounts in Penpot.

ntfy is an open-source push notification server (Apache 2.0, ~32k ⭐): you publish a message to a topic with a plain HTTP call (`curl -d "Message" http://your-vps/topic`), and any subscriber — mobile app, browser, script — receives it in real time. Self-hosting on ServOrbit gives you unlimited private topics with no rate limits, no third-party account and no monthly fee. You own your notification channel completely.

No. ntfy works over plain HTTP without a domain — your scripts and monitoring tools can send notifications to the VPS IP address directly. A domain adds HTTPS (recommended for notifications sent over the public internet) and browser Web Push API support, but the core use case — scripts and monitoring tools sending alerts to the ntfy mobile app — works on HTTP without a domain.

One line: `curl -d "Job done" http://your-vps:8080/your-topic`. Add a title with `-H "Title: Nightly backup"` and set priority with `-H "Priority: high"`. No SDK, no library, no API key — works in any shell environment where curl is available: cron, GitHub Actions, GitLab CI, AWX, Docker entrypoints, Python subprocess.

Yes. The official ntfy apps for Android (F-Droid / Play Store) and iOS (App Store) let you add any self-hosted ntfy server as a notification source. Enter your server URL (e.g. `http://your-vps:8080`) and subscribe to a topic. Notifications arrive as push even when the app is in the background — Android uses UnifiedPush (F-Droid) or FCM (Play), iOS uses APNs.

For a private VPS accessible only to your scripts, no authentication is needed. For additional security, run `docker exec <container> ntfy user add admin` to create an admin user, then set `NTFY_AUTH_DEFAULT_ACCESS=deny-all` so only authenticated users can publish/subscribe. Each script or monitoring tool gets its own access token via `ntfy token add`.

ntfy idles under 30 MB RAM with the default SQLite message cache. Disk usage depends on retention settings — messages expire after 12 hours by default and attachments are not stored server-side (they are referenced externally). A VPS with 512 MB RAM is more than sufficient for a personal or small-team ntfy instance handling thousands of notifications per day.

restic is the backup engine: encrypted, deduplicated, incremental and driven entirely from the command line. Backrest is a web UI and scheduler on top of it — same engine, same repository format, but repositories, plans, schedules, retention, restores and maintenance are managed in a browser instead of cron files and shell scripts. Your backups remain standard restic repositories you can open with the restic CLI at any time, so Backrest introduces no lock-in.

Anywhere restic can write, which includes every rclone remote: Amazon S3, Backblaze B2, Wasabi, MinIO, Azure Blob, Google Cloud Storage, SFTP/SSH, or a local or network-mounted disk. Backblaze B2 is the usual pick for a VPS — inexpensive, S3-compatible and, crucially, outside your server's own failure domain, which is the entire point of an off-site backup.

Yes, and you do. restic encrypts every snapshot locally, on the VPS, before anything is sent — the destination only ever receives opaque blocks. The repository password is the encryption key. Store it in a password manager: if you lose it, the backups become mathematically unrecoverable, and neither ServOrbit nor the storage provider can restore access.

The container itself is light: under 100 MB RAM at idle and a few hundred megabytes of image and cache — a 1 GB VPS is plenty. The real cost is at the destination, and deduplication keeps it modest: after the first full snapshot, later runs upload only changed blocks, so a 20 GB server with months of daily retention often fits in a few tens of gigabytes.

It backs up whatever is mounted into it. The ServOrbit recipe mounts the host's `/home`, `/root` and `/etc` read-only under `/host`, which covers user data and system configuration on a typical VPS. To protect other paths — an application data directory, a Docker volume — add the matching read-only mount to the compose file and it will show up in the plan's path picker.

Backrest shows the status and history of every plan in its UI, and runs scheduled `check` operations that verify repository integrity rather than merely reporting that the job started. For active alerting, configure a failure hook pointing at a webhook: a self-hosted ntfy topic works perfectly and pushes the failure to your phone the same night. That is how you avoid the classic scenario — discovering a backup that has been broken for three months at the exact moment you need it.

Meilisearch is an open-source full-text search engine (MIT, 57 k+ GitHub stars) designed for user-facing search: typo tolerance, results in under 50 ms, native support for Arabic, French and English. A SQL ILIKE query scans the full table and ignores typos — beyond a few thousand rows, it becomes too slow for a real-time search bar. Meilisearch pre-indexes your data and responds in milliseconds even across millions of documents, without modifying your primary database.

The Meilisearch binary itself runs under 50 MB RAM at idle. Actual consumption depends on your index size: an index of 100,000 products with several text attributes uses roughly 200–500 MB of RAM and similar disk space (Meilisearch pre-builds its inverted indexes for speed). A 1 GB RAM VPS is enough to start; move to 2–4 GB once your dataset exceeds a million documents or you are serving sustained search traffic.

Yes. Meilisearch's multilingual tokeniser automatically detects the language of each attribute and applies the right processing: n-gram segmentation for Arabic (handling the absence of standard word separators and RTL direction), diacritic normalisation and stop-word list for French. An index that mixes Arabic and French fields responds correctly to queries in both languages without any configuration — ideal for bilingual Morocco/MENA projects.

The ServOrbit provisioner automatically generates a strong, random `MEILI_MASTER_KEY` and starts Meilisearch in `production` mode. In production mode, every API call must include either the master key (in the `Authorization: Bearer <KEY>` header) or a scope-limited derived API key — the instance rejects any unauthenticated request. The master key is displayed once in your ServOrbit client area after deployment: store it in a password manager, as it cannot be recovered from the container if lost (only a restart with a new key is possible, which invalidates existing derived keys).

Yes, and that is the recommended practice. From the master key, you generate scope-limited API keys via the `/keys` endpoint: read-only on a specific index, search-only without write or delete access, access limited to a subset of attributes, or filter constraints (the user can only search within their own data). The search key can be embedded in plain text in your JavaScript bundle without risk — it cannot modify or delete data. The master key must never leave your backend.

No. Meilisearch is a search index, not a transactional database. The standard pattern: your application writes data to PostgreSQL (or any other database), then syncs it into Meilisearch (via a webhook, a Sidekiq/Horizon job, or a scheduled task) for indexing. Search queries go to Meilisearch; full data reads (product page, order, profile) stay in your primary database. The two are complementary: PostgreSQL guarantees transactional consistency, Meilisearch provides search speed and relevance.

Monica CRM (AGPL-3.0, 22 k+ stars) is a personal relationship manager, not a sales tool. Where business CRMs like Twenty or HubSpot track pipelines, leads and revenue, Monica tracks the human side: birthdays, personal notes, gift ideas, life events and follow-up reminders. It is designed for managing your personal and professional network — friends, family, mentors, clients — not a structured sales funnel.

No. Monica's registration and login flow works without any mail configuration. The first user to register on a fresh instance automatically becomes the administrator — no verification email is sent. SMTP is only needed if you want Monica to send reminder emails or password-reset links; both features remain available through the dashboard without SMTP.

Monica v4 officially supports MySQL and MariaDB only. The ServOrbit recipe uses MariaDB 11, the recommended open-source MySQL-compatible database. PostgreSQL is not supported in Monica v4 — the application relies on MySQL-specific features and the ORM configuration targets MySQL/MariaDB exclusively.

Monica itself typically uses under 256 MB of RAM at rest. MariaDB adds 150–300 MB depending on query concurrency, and Redis under 50 MB. In total, a 1 GB VPS is comfortable for personal use (up to ~5 users and tens of thousands of contacts). Scale to 2 GB if you plan to host a small team or run large imports regularly.

Yes. Monica imports vCard (.vcf) files, which is the standard export format for iPhone (via iCloud), Android (via Google Contacts) and desktop tools (Apple Contacts, Outlook, Thunderbird). Export your contacts from your phone or cloud service, upload the .vcf file in Settings → Import, and Monica maps fields automatically. CSV import with custom field mapping is also supported.

Monica is a progressive web app (PWA) — you can add it to your phone's home screen from the browser (Share → Add to Home Screen on iOS; Add to Home Screen in Android Chrome) and it behaves like a native app with offline caching. There is no dedicated native iOS or Android app, but the PWA works well on mobile.

SearXNG is an open-source metasearch engine that aggregates results from Google, Bing, DuckDuckGo and 280+ sources in a single query, without tracking you or storing your history. Self-hosting it on your VPS gives you a private search URL for your team and AI agents — no per-query cost, no rate limits and no data sent to third parties.

Yes. Enable the JSON format in SearXNG's `settings.yml` (`formats: [html, json]`), then point your AI tools to `https://your-domain.com/search?q=<query>&format=json`. Open WebUI, n8n, Flowise, LangChain and CrewAI all support SearXNG natively as a web search backend.

SearXNG (Python container) uses under 256 MB RAM, Redis adds ~30 MB. A 1 GB ServOrbit VPS is sufficient for personal use or a small team. For heavy AI agent traffic or multiple concurrent users, a 2 GB VPS is more comfortable.

The simplest method is HTTP Basic Auth in Nginx — only users with credentials can access the interface. For API-only use (AI agents), disable the HTML interface in `settings.yml` and restrict allowed IP ranges in Nginx. You can also enable `limiter: true` in settings to protect a public instance from abuse (Redis is required for the rate limiter).

SearXNG uses aggregation techniques similar to any metasearch engine. For personal or internal team use, the risk is minimal. For heavy public use (millions of queries/day), some engines may block your IP. Enable source rotation in `settings.yml` and use Redis to cache frequent results — this significantly reduces load on each individual engine.

No. The AI auto-tagging feature is entirely optional. Karakeep works as a full bookmark manager — saving, crawling, screenshotting and full-text indexing — without any AI key. When you add `OPENAI_API_KEY` or `OLLAMA_BASE_URL`, automatic tag and summary generation activates on new saves.

The three containers (Karakeep app, Meilisearch, and headless Chrome) use approximately 800 MB–1.2 GB at idle. A 2 GB ServOrbit VPS is the recommended minimum. If you're also running Ollama on the same VPS for local AI tagging, a 4 GB VPS is more comfortable — Ollama needs at least 4 GB for a small model like `phi3:mini`.

Yes. Karakeep supports importing from Pocket (JSON export), Netscape bookmark files (exported by all major browsers, Raindrop.io and Pinboard), and its own backup format. Go to Settings → Import in your instance to upload the file. Large imports (thousands of bookmarks) are processed in the background — the import itself is fast, full-text indexing happens asynchronously.

Yes. If Ollama is running on the same VPS (from the ServOrbit marketplace or installed manually), add `OLLAMA_BASE_URL=http://localhost:11434` to the Karakeep environment in your `docker-compose.yml`. In the web interface, go to Settings → AI and select your preferred Ollama model. Karakeep will use it for tagging and summarisation with no API cost and no data leaving your server.

Yes. Karakeep ships a Progressive Web App (PWA): open your instance URL in a mobile browser, tap 'Add to Home Screen', and it installs like a native app. The native share sheet integration (iOS and Android) lets you send any link from any app directly to your Karakeep instance with a single tap.

Gatus is a config-as-code health monitoring and status page tool (~11.7 k stars, Apache 2.0): you define your endpoints and their health conditions in a versionable YAML file. Uptime Kuma is a UI-first uptime monitor — great for adding monitors without touching a config file. Gatus offers richer health conditions (response time, TLS expiry, body regex, DNS resolution) and produces a public-facing status page suited for sharing with your end users.

No. Gatus works directly on your VPS IP address — the status page is accessible at `http://your-vps-ip:8080` right after deployment. A domain name is recommended for a customer-facing status page (to proxy Gatus behind nginx with HTTPS and a subdomain like `status.your-domain.com`), but internal monitoring and alerting work immediately without a domain.

SSH into your VPS and edit `/opt/stacks/gatus/config/config.yaml`. Add a new block under `endpoints:` with the URL, interval and conditions. Restart with `cd /opt/stacks/gatus && docker compose restart gatus`. The new endpoint appears on the status page within seconds. No browser, no UI — just a text file you can version-control in a git repository.

Gatus includes 40+ alert integrations: Slack, PagerDuty, OpsGenie, Discord, Microsoft Teams, Telegram, Pushover, ntfy, GitHub Issues, email, custom webhook, Mattermost, Gotify and more. Configure the channel once in the `alerting:` block of your config, then reference it by type from each endpoint. Each endpoint supports failure thresholds (e.g. `failure-threshold: 2` to alert only after 2 consecutive failures) and success thresholds for recovery alerts.

Simply change the `url:` prefix in your endpoint definition. For TCP: `url: "tcp://db.internal:5432"` with condition `[CONNECTED] == true`. For DNS: `url: "dns://ns1.example.com"` with `[DNS_RCODE] == NOERROR`. For TLS expiry: keep `url: "https://your-domain.com"` and add `[CERTIFICATE_EXPIRATION] > 14d` — Gatus alerts when fewer than 14 days remain before the certificate expires. For ICMP: `url: "icmp://192.168.1.1"`. All endpoint types share the same condition syntax and the same alert channels.

Grist is a self-hostable open-source spreadsheet-database (Apache-2.0, ~11 k GitHub stars). Unlike Google Sheets or Excel, Grist stores data in typed relational tables with explicit references between tables, Python formulas executed server-side (full library access) and a REST API generated automatically on every document. It is the open-source alternative to Airtable — no subscription, no vendor lock-in. Find it in the <a href="/marketplace/developpement/grist">ServOrbit catalogue</a> or reach us at [email protected].

No. Grist stores each document as a SQLite file in the /persist/docs/ volume. No external service is required: no PostgreSQL, no Redis, no Celery. SQLite handles thousands of rows per table comfortably. For very large multi-user instances, Grist can use PostgreSQL as its home database — but the standard single-container deployment uses SQLite for everything. A single 1 GB RAM VPS is sufficient for personal or small-team use.

Every Grist document automatically exposes a REST API at http://your-vps-ip:8484/api/docs/<docId>/tables/<tableName>/records. You can list records (GET), create (POST), update (PATCH) or delete (DELETE) without any additional configuration. Retrieve the docId from the document URL in the web interface. Use this API with n8n, Make, or any HTTP client to integrate your Grist data into automation workflows. API key authentication is available in account preferences.

Yes. Grist supports real-time collaboration: multiple users can edit the same document simultaneously, with changes propagating in under a second and a full audit log. Sharing is done document by document via the Share menu, with three roles: viewer (view-only), editor, owner. For a multi-user system with real email authentication (not the GRIST_DEFAULT_EMAIL of the initial deployment), configure an OIDC provider such as Google Workspace, Authentik or Keycloak via the GRIST_OIDC_* environment variables.

Grist documents are SQLite files in the /persist/docs/ volume — one .grist file per document. Copy them like any file. For automated, versioned backups, use Backrest (also in the ServOrbit catalogue): it snapshots the volume via restic and pushes encrypted increments to S3, Backblaze B2, or SFTP without stopping Grist. Grist also keeps a per-document snapshot history in the interface (Document menu → History) — handy for restoring a previous version without SSH access.

That upkeep is yours. Our templates install open source software on your VPS and then hand you the keys: new versions and security patches are your responsibility, like everything else running on an unmanaged server — the client area offers installation and removal, not version upgrades. Follow the publisher's release channel and take a snapshot from your client area before each update, so you can roll back if it goes wrong. If you would rather delegate, VPS administration is available as an option — write to [email protected].

Logto is a self-hosted OIDC/OAuth 2.0 platform you deploy on a ServOrbit VPS from the Marketplace. Once deployed, create your application in the admin console (port 3002 via SSH tunnel), get your Client ID and OIDC endpoint URL, then install the official SDK for your framework (`@logto/react`, `logto-python`, etc.). In 15 lines of configuration, your users can register, sign in with credentials or social providers (Google, GitHub…), and receive a signed JWT that your API verifies with a single middleware line.

Yes. Logto's ENDPOINT URL is the OIDC issuer: it is written into every JWT token your instance issues. This setting is fixed at first boot and cannot be changed without resetting the entire database. Choose your final domain before deploying. If you need to change the domain later, delete the `logto_db` volume, re-deploy with the new domain, then reconfigure all your applications.

These are three authentication tools with distinct roles. Authelia is an authentication proxy (forward auth): it adds MFA and SSO in front of your existing apps without changing their code, ideal for protecting a Grafana or Nextcloud. Authentik is a full identity provider (OIDC, SAML, LDAP) for centralising SSO across your self-hosted infrastructure. Logto is an auth SDK platform: you integrate it into the code of your own product to add user registration, social login, MFA and OIDC tokens, just like Auth0 or Clerk.

The Logto admin console is bound to port 3002 on localhost only for security reasons. Open an SSH tunnel from your local machine: `ssh -L 3002:127.0.0.1:3002 root@<your-vps-ip>`, then access `http://localhost:3002/console` in your browser. This approach ensures that access to user and application management is only possible from a machine with SSH rights on the VPS.

Yes. In the Logto console, you can create as many Applications as you need (SPA, Native, Backend, Machine-to-Machine). Each application gets a unique Client ID and its own redirect URIs. A single Logto VPS can thus centralise authentication for several projects: a React front-end, a FastAPI API, a Flutter mobile app — each with its own roles and access policies configured independently.

Cal.com is the open-source equivalent of Calendly, self-hosted on your VPS. The feature set is very similar: event types, calendar sync, automatic video conferencing, webhooks. The key difference: with Cal.com your booking data stays on your server, there is no plan limit (all event types are free) and you plug in your own Google/Zoom API keys. Calendly is the right choice if you don't want to manage a server; Cal.com is the right choice if you want full control.

No, not without resetting the instance. NEXT_PUBLIC_WEBAPP_URL is embedded in every booking link, OAuth callback and NextAuth cookie at first start. Changing the domain afterwards breaks authentication for all existing users. Choose your final domain before deploying. If you must change it, delete the calcom_db volume, redeploy with the new domain, then reconfigure Google Calendar integrations and webhooks.

SMTP is optional to create the admin account (the first-run wizard doesn't ask for it). But it is required to send booking confirmations and calendar invites to guests — without SMTP, Cal.com works for booking but attendees receive no notifications. Configure it in Settings → Email after first start. A transactional SMTP provider (Gmail App Password, Mailgun, Brevo) with 100–300 sends/day is enough for most use cases.

In Cal.com, go to Settings → Calendars → Connect Google Calendar. You will be redirected to the Google authorization page — accept the calendar read/write permissions. Cal.com reads your existing events to block busy slots and automatically writes each new booking to your Google Calendar. For this to work, you must set up Google OAuth credentials in your environment variables (GOOGLE_API_CREDENTIALS). Alternatively, Cal.com supports CalDAV to connect to Nextcloud Calendar, Fastmail or any CalDAV server.

Cal.com (Next.js) + PostgreSQL 16 run well on a 2 GB RAM VPS for individual use or teams of fewer than 10 people, up to 300–500 bookings per day. For larger teams (> 10 users, hundreds of event types) or if you're hosting other apps on the same VPS, prefer 4 GB RAM. Disk usage is low: an active instance with 10,000 bookings uses only ~500 MB of database storage.

No. Without SMTP you can still create an account and verify your email address: the verification link is printed in the Docker logs. Run `docker compose logs reactive-resume | grep verify` and click the URL to activate your account. SMTP remains optional and only applies to future email notification features.

Yes. Set the environment variable `DISABLE_SIGNUPS=true` in your Docker configuration and restart the container (`docker compose restart reactive-resume`). New visitors will no longer be able to register — only existing accounts can sign in. To manage users or invite new ones, use the REST API or admin settings.

Not without a full reset procedure. Reactive Resume embeds `APP_URL` in JWT tokens and OAuth redirects at first start: changing the URL breaks all active sessions and all public resume URLs. If you must migrate to a new domain, back up your data (`docker exec db pg_dump -U postgres postgres > backup.sql`), delete the Docker volumes, redeploy with the new domain, and restore the backup — then reconfigure `APP_URL`. Plan your final domain before first deployment.

No, since version 5.1.0. PDF generation is entirely client-side via the `@react-pdf/renderer` library: the PDF is produced directly in your browser, without any Chrome, Puppeteer or Browserless process on the server. This reduces the server's memory footprint by approximately 700 MB and removes an infrastructure dependency. If your instance is still running a version before 5.1.0, update the Docker image: `docker pull amruthpillai/reactive-resume:latest && docker compose up -d`.

Two Docker volumes carry all instance data. Full backup: `docker run --rm -v reactive_resume_db:/data -v $(pwd):/backup alpine tar czf /backup/rr-db.tar.gz /data` and `docker run --rm -v reactive_resume_data:/data -v $(pwd):/backup alpine tar czf /backup/rr-data.tar.gz /data`. Direct SQL dump: `docker exec db pg_dump -U postgres postgres > backup.sql`. Restore by mounting the archives onto fresh volumes and restarting with `docker compose up -d`. Make sure `APP_URL` is identical between source and destination — otherwise JWT tokens will be invalid.

Plan for 4 GB of RAM as a minimum and 8 GB to be comfortable: ClickHouse keeps its indexes and marks in memory, and an aggregation that exceeds the available memory is aborted rather than swapped to disk. Two vCPU are enough to parallelise queries, four are comfortable. Disk is what really decides: budget 50 to 100 GB of NVMe SSD depending on your retention, knowing that compression typically divides the raw volume by five to ten. At rest, before any query, the installation uses around 270 MB of RAM.

No, and that is not its job. ClickHouse is an analytics (OLAP) database: it is built to scan and aggregate very large tables, not to serve the small transactional reads and writes of a web application. It offers no real transactions, its updates and deletes are asynchronous mutations rather than immediate operations, and reading a single row is slower than in PostgreSQL. The pattern that works is to run both on the same VPS: PostgreSQL or MySQL for the application, ClickHouse for logs, metrics and reporting.

The installation creates an `admin` account with a password generated for your server, which you read on the application card in your client area; the `default` account that the original image ships without a password is removed at startup. ClickHouse ships its own browser SQL console at the `/play` path: if you attached a domain it answers on `https://<your-domain>/play`; otherwise open a tunnel with `ssh -L 8123:127.0.0.1:8123 root@<your-vps-ip>` and go to `http://localhost:8123/play`. The server is never reachable directly on the public IP address.

Two complementary levels. At the machine level, your VPS backup option snapshots the whole disk, Docker volumes included: that is disaster recovery, and it is the net to enable first. At the database level, ClickHouse offers a `BACKUP TABLE … TO Disk(…)` command that produces a consistent backup you can then ship off the server: that is what you need to restore a single table without rolling the whole server back. Avoid copying `/var/lib/clickhouse` while the service is running — in-flight part merges would make the copy inconsistent.

Put retention in the schema, not in a cleanup script. Declare a TTL when you create the table — for example `TTL event_date + INTERVAL 90 DAY` — and partition by month with `PARTITION BY toYYYYMM(event_date)`: ClickHouse then drops fully expired partitions in the background, which costs almost nothing, instead of deleting rows one by one. Also insert in batches of several thousand rows rather than row by row, because single-row inserts create a swarm of small parts and trigger expensive merges. If queries start slowing down, look at `system.parts` and `system.merges`.

No, the official Node-RED image enables no authentication by default. The editor is accessible to anyone who can reach port 1880. If you attach a public domain, add `adminAuth` to `/data/settings.js` before exposing the URL: enter a username and the bcrypt hash of your password (obtained with `node-red-admin hash-pw` inside the container), then restart the service.

Yes. The Marketplace template mounts a named Docker volume `node-red-data` on `/data`. Node-RED saves flows and configuration there as soon as you click Deploy. A VPS or container restart automatically reloads your flows and resumes their execution. To back up your automations, take a VPS snapshot from the client area or export your flows as JSON from the editor menu.

In the editor, drag an `mqtt in` or `mqtt out` node from the palette. Double-click it to configure: enter your broker address (IP or FQDN), the port (1883 by default, or 8883 for TLS), and the topic to subscribe to or publish on. If your broker requires authentication, add it in the node configuration. Node-RED keeps the connection permanently and receives messages from your sensors in real time.

From the editor, open the main menu (hamburger icon) then Manage palette → Install tab. Search for the node by name (e.g. `node-red-contrib-telegrambot`, `node-red-node-mysql`). Click Install: Node-RED downloads the npm module, installs it in `/data/node_modules` and reloads the palette. No container restart is needed. If the installation fails, check that the VPS has internet access (npm registry).

Node-RED and n8n target different profiles. Node-RED is lower-level and developer/IoT oriented: it handles the MQTT protocol natively, lets you wire custom processing with JavaScript functions, and integrates easily with physical hardware. n8n is more oriented toward business automation: it offers ready-made connectors for hundreds of SaaS services (Slack, Gmail, Airtable…), a more no-code workflow interface, and per-run error handling. Both are available in the ServOrbit Marketplace. The right choice depends on your use case: IoT / real-time flows → Node-RED; SaaS integrations / business workflow → n8n.

Yes. When port 22000 (the direct sync port) is not reachable, Syncthing falls back automatically to global relay servers. Sync still works with slightly higher latency. Open port 22000 in the VPS firewall if you need maximum transfer speed — this is optional.

Install Syncthing on the device (desktop, laptop, phone), copy its Device ID from its web UI, then add it as a Remote Device in the VPS Syncthing interface. The device will see a pairing request to approve. After pairing, share the folders you want to keep in sync.

No. The web interface has no authentication by default. The very first action after accessing it is to set a username and password in Settings > GUI. Device-to-device authentication uses cryptographic certificates automatically — no manual key exchange needed.

Syncthing focuses exclusively on encrypted peer-to-peer sync — no web file browser, no calendar, no apps. Nextcloud is a full collaborative platform with a web interface and mobile apps. Choose Syncthing for privacy and low resource use; choose Nextcloud for a complete cloud platform.

Windmill ships with `[email protected]` as the username and `changeme` as the password. Change the password immediately after your first login under Settings → Users. Both the email and password can be updated.

n8n and Activepieces focus on connecting SaaS services with visual, low-code flows. Windmill targets developers who want to write real code (Python, TypeScript, Go, Bash, SQL) and have it automatically orchestrated, versioned and exposed as APIs and UIs. The two approaches are complementary and both available on the Marketplace.

A minimum of 2 vCPU and 4 GB RAM is recommended to run the Windmill server, one default worker and one native worker. Add extra worker containers if you run many concurrent Python jobs or heavy compute workloads.

Not for basic use — the interface is accessible via the IP address or the free ServOrbit subdomain provided at installation. A domain name is recommended if you want to use OAuth providers for authentication or webhooks that require a stable HTTPS URL.

Yes. The default worker mounts the VPS Docker socket and runs in privileged mode, allowing scripts to spin up ephemeral Docker containers for isolated processing. This capability is available on all ServOrbit VPS instances and requires no additional configuration.

Kaneo has no default credentials. The first time you open the URL, a sign-up form appears: enter your name, email and a password. The first account created automatically gets admin rights. Once your team is set up, close registration under Settings → General.

Vikunja is a full-featured task manager with Kanban, Gantt, CalDAV sync and recurring tasks — closer to Asana or TickTick. Kaneo is deliberately simpler: Kanban boards, GitHub integration and webhooks, without the extra views. Choose Kaneo if your team lives in code and GitHub; Vikunja if you need Gantt charts or calendar sync.

No. The ServOrbit deployment configures Kaneo with DISABLE_EMAIL_OTP_SIGN_IN=true: login uses standard email and password with no email sending required. SMTP is only needed if you want to re-enable magic-link (OTP) login or send notifications.

No. Kaneo works without a custom domain — you can access it through the ServOrbit-assigned URL (based on your VPS IP). A domain is recommended for a memorable URL and easier team sharing, but is not required for deployment.

All Kaneo data lives in the PostgreSQL database. To create a backup: `docker exec kaneo-postgres-1 pg_dump -U kaneo kaneo | gzip > kaneo-backup.sql.gz`. To restore: `gunzip -c kaneo-backup.sql.gz | docker exec -i kaneo-postgres-1 psql -U kaneo kaneo`. The Docker volume `postgres_data` holds the raw PostgreSQL files — you can also back it up directly.

Kestra is a YAML-based open-source workflow orchestration platform. Unlike a cron script, each Kestra flow is versioned in Git, observable (per-task logs, full execution history) and automatically retryable on failure. You trigger pipelines by cron, webhook or API call, and you visualise your task dependency graph in a dedicated web interface.

n8n is suited for no-code API automation: connecting SaaS tools, reacting to webhooks, filling Google Sheets. Kestra is built for code-first data and ETL pipelines: YAML workflows versioned in Git, Python/SQL/Bash scripts, isolated Docker runners and full traceability. Choose Kestra if your team writes code and needs a reproducible audit trail; prefer n8n for a drag-and-drop SaaS integrations automator.

Kestra runs on the JVM and typically consumes 512 MB to 1 GB of RAM at startup, plus PostgreSQL (around 150 MB). A VPS with 4 GB RAM and 2 vCPU is sufficient for light to moderate use (scheduled flows, a few simultaneous webhooks). If your flows launch Docker tasks (isolated Python scripts), plan for 8 GB of RAM. Minimum disk: 10 GB for Kestra data and logs.

Yes. Kestra mounts the Docker socket and can run any Docker image as a task via the `io.kestra.plugin.scripts.runner.docker.Docker` plugin. Each script (Python, Bash, Go...) runs in its own isolated container with its own dependencies, keeping the host server clean. Results and logs are captured by Kestra and visible in the execution history.

ServOrbit configures Kestra with HTTP basic authentication enabled (username `[email protected]` + auto-generated password). Port 8080 is bound to 127.0.0.1 — never exposed directly to the internet. To harden security: attach a domain and enable HTTPS (nginx + Let's Encrypt managed by AWX); keep your generated password in a safe place; and regularly back up the PostgreSQL database that contains all your flows and execution history.

Garage is an S3-compatible object store written in Rust by the Deuxfleurs collective and published under the AGPLv3 licence. Object storage gives you an endpoint to put and get files through a standard API, rather than a mounted disk: it is what backup tools (restic, Borg) use, along with applications storing user uploads and static sites served behind a CDN. Because the interface is standard S3, your existing tooling works unchanged.

No, and that is a deliberate design choice by the project. Administration goes through the `garage` command-line tool and an HTTP admin API: the daemon stays small and its operational surface narrow. Community projects provide a browser interface on top of that API if you want one. Your S3 credentials themselves are shown in your ServOrbit client area.

For the common case — an S3 endpoint for backups and applications — yes. Garage is lighter, and its AGPLv3 licence holds no feature back for a paid edition, unlike what happened to MinIO's community edition (admin console removed in 2025, then community Docker images no longer published). They are two distinct projects, not a character-for-character replacement: validate your specific integrations before migrating.

No, and that deserves to be said plainly. A single-node deployment keeps one copy of your objects, on one disk: it does not replace a backup. Garage's replication is designed for a cluster of several machines, possibly across sites — the same binary supports it once you add nodes. As long as you have one, keep your usual backup discipline.

The service itself is very frugal: measured at roughly 3 MiB of memory at idle on a single-node deployment. What sizes your server is the volume of data you intend to store, not Garage. An entry-level VPS is enough to run the daemon; pick the disk for what you will put in it, and remember that a single node offers no redundancy.

Whisper recognises 99 languages including Arabic, French, English, Spanish and Moroccan Darija. Transcription and translation to English are handled by the same model, selected via the `task` parameter (transcribe or translate). The default `base` model covers all these languages; `large-v3` improves accuracy for low-resource languages.

The `base` model (default `ASR_MODEL=base`) runs comfortably on 1 GB of RAM and 1 vCPU. It delivers solid accuracy for clear speech in common languages. For noisy recordings or less common accents, `small` is more accurate and works well with 2 GB of RAM. The `large-v3` model offers the best accuracy but requires at least 8 GB of RAM and is recommended for GPU VPS plans.

Whisper is deployed as a REST API with a Swagger UI at `/docs` for interactive testing. It does not include a standalone web application with a file upload form. To integrate Whisper into a workflow without coding, tools like n8n or Make allow you to call the `/asr` API directly from an automated workflow. From the command line, `curl -F "[email protected]" https://your-address/asr?output=txt` is all you need.

Yes. The `/asr` endpoint is compatible with the OpenAI transcription API: any library or integration that calls the OpenAI API can be redirected to your instance simply by changing the base URL (`base_url`) and removing the API key. The `output` parameter is equivalent to OpenAI's `response_format`. Note: the `/asr` endpoint is not identical to OpenAI's `/v1/audio/transcriptions` — some libraries that check the exact path may need a minor adjustment.

No. All processing is done locally on your VPS: audio files are kept in memory during transcription and are never written to disk or sent to OpenAI or any third-party service. Whisper is a machine learning model that runs entirely inside your container. This is precisely the benefit of self-hosting for sensitive content: interviews, medical data, internal company recordings.

ToolJet shows a setup wizard on first open. It asks for your full name, email address and a password. The first account created automatically becomes the super-admin of the workspace. No email confirmation is required — you are redirected straight to the editor after submission.

No. An SMTP server is entirely optional. The admin account is created via the in-browser wizard, with no email confirmation needed. SMTP is only useful if you want to enable password reset by email or invite new users by email. You can configure SMTP later in Settings → Organization without needing to redeploy.

No. ToolJet CE is AGPL-3.0 licensed — no seat limits, no app limits, no per-user fees. The only constraint is your VPS resources. A 2 GB RAM VPS handles dozens of concurrent users and dozens of apps comfortably. For hundreds of users or very heavy queries, a 4–8 GB RAM VPS is recommended.

No. ToolJet is configured with `requireDomain: false` on ServOrbit. TOOLJET_HOST accepts both `http://your-ip` and `https://your-domain.com`. Without a domain, public access is not enabled: use an SSH tunnel — `ssh -L 8096:127.0.0.1:8096 root@your-vps-ip` — then open `http://localhost:8096` in your local browser. Attaching a domain later only requires updating `TOOLJET_HOST` in the `.env` file and restarting the containers.

Retool is a hosted, closed-source service billed per user per month (approximately $10–25 per seat). ToolJet CE is fully open source (AGPL-3.0), self-hosted on your VPS and free beyond the hosting cost. The feature set is comparable — drag-and-drop canvas, data source connectors, JavaScript actions, role-based access control, app versioning. Retool has a slightly larger connector library; ToolJet 3.0 (2026) added AI-native app prototyping. The main advantage of ToolJet CE: all your business data stays in your infrastructure, with no transfer to a third party.

Mautic is an open-source marketing automation platform: it covers email campaigns, contact segmentation, lead scoring, landing pages and event-driven workflows. Listmonk is a high-performance newsletter tool focused on bulk sending. Mautic is better suited when you need behavioural automation (drip sequences, scoring, conditional branches); Listmonk is a better fit when you simply need to send the same newsletter to a large list.

Yes. To send campaigns, Mautic must be connected to an SMTP relay (Amazon SES, Mailgun, Brevo, SendGrid, Postmark…). Cloud VPS IP ranges are generally blocked by major ISPs and email providers, making direct sending impossible. Configure your relay in Settings → Email Settings as soon as the installation wizard is done, and send a test email to confirm deliverability before launching any campaign.

Mautic imposes no software limit on the number of contacts — the real ceiling is your VPS disk and memory. In practice, a 4 GB RAM VPS comfortably handles databases of 50 000 to 100 000 contacts with all features active (campaigns, tracking, scoring). For lists of several hundred thousand, tune MySQL innodb_buffer_pool_size (60–70 % of available RAM) and consider a dedicated database VPS.

The Mautic installation wizard checks several PHP prerequisites (mbstring, pdo_mysql, intl, gd extensions…). If the check fails on ServOrbit, it is usually because the container has not yet had time to start fully. Wait 2 minutes and reload the page. If the problem persists, check the logs with `docker compose logs mautic_web` from your VPS and share them with support through the client area.

Yes. Mautic offers native integrations with Salesforce, SugarCRM, HubSpot, Zoho and Pipedrive through its CRM plugins. For Twenty (which is also in the ServOrbit catalogue), you can use the Mautic and Twenty REST APIs combined with an automation tool like n8n to synchronise contacts and events between the two platforms.

Enter `admin` as the username and the generated password (ADMIN_PASSWORD in your ServOrbit client area under the credentials tab). Authentication is enforced from the first boot — the instance is never open without credentials.

No. Without a domain, access it via an SSH tunnel: `ssh -L 7860:127.0.0.1:7860 root@your-vps-ip`, then open `http://localhost:7860` in your browser. Attaching a domain enables direct HTTPS access — ServOrbit automatically configures the nginx proxy and TLS certificate.

Yes. Use the Ollama component on the canvas and set its base URL. If Ollama is installed on the same VPS via the ServOrbit Marketplace, it is reachable from inside the LangFlow container at `http://host.docker.internal:11434`.

Both are visual LLM pipeline builders. LangFlow is Python-native and targets developers who want to write custom components or export clean Python code from their flows. Flowise is more no-code oriented, with a simpler canvas. The two share the LangChain lineage but have diverged in developer profile and tooling.

Export each flow individually from the canvas menu (JSON export). For a full backup, copy the SQLite database: `docker cp langflow-langflow-1:/app/data/langflow.db ./langflow-backup.db`. Restore by copying it back and restarting the container.

Linkwarden has no default credentials. On first open, click Sign Up and create your account with an email address and password — the first account automatically becomes the instance owner. No email confirmation is required. Go immediately to Settings → Users to close sign-ups if you want invitation-only access.

Yes. Linkwarden uses NextAuth.js for session management, which anchors the public URL (NEXTAUTH_URL) into session cookies on first boot. The domain must be chosen and DNS-configured before deployment. Changing it afterwards requires resetting the database and re-inviting all members — it is best to decide upfront.

For a team of 5–15 people, **2 vCPU and 2 GB RAM** under Ubuntu 24.04 provides comfortable headroom. Linkwarden's Docker image bundles Playwright with Chromium for automatic page archiving — this raises RAM consumption to around 400–600 MB under load. On a 1 GB VPS, you can disable archiving with DISABLE_NEXT_GENERATION_ARCHIVAL=true, bringing the footprint below 256 MB.

Both manage bookmarks but with distinct angles. **Karakeep** (formerly Hoarder) targets personal use: AI-powered automatic tagging, semantic search and a PWA. **Linkwarden** targets team collaboration: shared collections, granular per-member permissions (viewer/editor/owner), comment threads and a multi-user browser extension. Choose Linkwarden to centralize team or agency research; choose Karakeep for AI-enhanced individual use.

By default, anyone with your instance URL can sign up. To close registrations, set the DISABLE_NEW_SIGN_UPS=true environment variable from your ServOrbit client area. Existing members keep access; only owners will be able to create new accounts from the admin panel. For per-collection roles and permissions, use Settings → Users.

DrawDB is an open-source entity-relationship diagram (ERD) editor (AGPL-3.0, ~39 k stars). It lets you visually model database tables, define FK relationships and export SQL DDL scripts for MySQL, PostgreSQL, SQLite, MariaDB and SQL Server — entirely in the browser, with no installation or account required.

No. DrawDB keeps diagram state in your browser's localStorage. The Nginx container processes no data — it only serves static files. To persist your schema across browsers or devices, export the JSON file and commit it to Git.

DrawDB generates SQL DDL for MySQL, PostgreSQL, SQLite, MariaDB and Microsoft SQL Server. Select the dialect from Export → SQL before copying the script. The DDL includes CREATE TABLE statements with column types, NOT NULL, PRIMARY KEY, FOREIGN KEY and DEFAULT constraints.

Yes. Paste your CREATE TABLE statements into DrawDB's SQL import dialog and it reconstructs the ERD diagram automatically — including detected FK relationships. Ideal for documenting a legacy database or quickly visualising an unfamiliar schema before modifying it.

No. DrawDB works without a domain: the interface is accessible directly on the port shown in your ServOrbit client area (3060 in the catalogue, but the effective port may differ if that port was already taken). Without a domain, no direct public access is available: open an SSH tunnel (`ssh -L 3060:127.0.0.1:3060 root@<your-ip>`) and browse to `http://localhost:3060`.

The default login is [email protected] with password MyPassword. Change both immediately after your first login in Administration → Your Profile.

No. Mealie works fine on a plain IP address. A custom domain is recommended for internet access with a valid TLS certificate, but not required for local or VPN-only use.

Mealie stores recipes, images and settings in the /app/data volume on your VPS. Back up this directory regularly to protect your library. You can also export the entire library as JSON from the interface.

Yes. Mealie supports multiple users with distinct roles: administrator, user (can add and edit recipes) and viewer (read-only). Create accounts from Administration → Users.

Mealie parses the JSON-LD Recipe markup on the target page and automatically extracts the title, ingredients, steps and main photo. For sites without structured markup, a fallback scraper takes over. If the result is incomplete, the manual editor lets you fill in missing fields.

Seafile focuses exclusively on file sync and sharing; it has no calendar, mail or app store. That makes it significantly lighter — typically half the RAM of Nextcloud on the same VPS. Choose Seafile for raw file sync performance, Nextcloud if you need a full collaboration suite.

Syncthing is peer-to-peer: every device syncs directly with the others, no central server. Seafile is client-server: all devices sync through the central VPS. Seafile supports multiple users, permissions, link sharing and a web interface; Syncthing is designed for one- or two-device use cases without account management.

Yes. When you create a library, you can opt for client-side encryption. The passphrase never leaves your device — the server stores only encrypted blocks and cannot recover your files even if someone gains access to the VPS. Warning: if you lose the passphrase, the files are permanently unrecoverable.

IT-Tools is an open-source web application (MIT, ~25 k stars) that brings together 60+ developer utilities — JWT decoder, SHA-256/MD5 hash generators, UUID v1/v4, base64 encoder, regex tester, JSON formatter and more. All processing happens in the browser: no data is sent to a server.

No. Every IT-Tools utility runs its calculations in JavaScript in your browser. The Nginx container only delivers the application's static files — it never receives, processes or transmits your inputs. Your JWT tokens, API keys and hashes stay entirely on your machine.

No. IT-Tools works without a domain: the interface is accessible directly on the port shown in your ServOrbit client area (3765 in the catalogue; the effective port may differ if that port was already taken). Without a domain, open an SSH tunnel (`ssh -L 3765:127.0.0.1:3765 root@<your-ip>`) and browse to `http://localhost:3765`.

IT-Tools has no built-in authentication. To restrict access: (1) place it behind a reverse proxy (Nginx or Caddy) with HTTP Basic Auth; (2) expose it only on a private VPN network; or (3) use the ServOrbit firewall to open the port only to your authorised IP ranges.

IT-Tools is extremely lightweight: the Docker image is approximately 20 MB and the Nginx container uses only a few megabytes of RAM at idle. It requires no database and runs comfortably on any 512 MB VPS without impacting other services.

Django Stack is a preconfigured VPS template that automatically installs Python 3.12, Gunicorn, Nginx, and PostgreSQL 16. It is designed for Python developers who want to deploy a Django application to production without manually configuring server components.

Python 3.12 from the deadsnakes PPA. This version brings 30–60 % performance improvements over Python 3.10 on typical Django request cycles. You can install other Python versions in parallel via the deadsnakes PPA and use virtualenv to choose the version per project.

Install Redis with `apt install redis-server`, add `celery` to your requirements.txt, then create a Supervisor configuration for your Celery worker under /etc/supervisor/conf.d/. Django Stack is designed to host both Gunicorn and Celery workers on the same VPS without additional system package configuration.

Yes. Create one virtualenv per project in /var/www/, one Nginx server block per domain (each pointing to a distinct Gunicorn port), and one Supervisor configuration per Gunicorn process. Each project is fully isolated — its dependencies, process, and configuration do not interfere with each other.

2 GB for a Django application with PostgreSQL and 3 Gunicorn workers. Plan for 4 GB if you add Celery workers or a loaded Redis cache. Each Gunicorn worker uses approximately 100–200 MB depending on your application size; adjust the number of workers accordingly.

Bytebase is an open-source database DevOps platform (MIT license) that brings a structured review workflow to SQL migrations. It lets you submit, validate and deploy schema changes safely, with 200+ automatic lint rules, a full audit trail, and GitOps integration for PostgreSQL, MySQL, MariaDB, MongoDB, Redis, ClickHouse and 20+ other engines.

Bytebase supports 20+ database engines: PostgreSQL, MySQL, MariaDB, MongoDB, Redis, ClickHouse, SQL Server, Oracle, TiDB, Snowflake, Spanner, OceanBase and more. It connects to your existing database servers as a client — it does not replace your data infrastructure, it orchestrates it.

Yes. The Community Edition is free with no user limits and covers the full change management workflow, SQL editor and audit trail. Enterprise features (SSO, fine-grained RBAC, data masking, custom approval workflows) require a paid plan. On ServOrbit, you only pay for the VPS — Bytebase itself costs nothing.

Bytebase runs comfortably on 1 GB RAM. The single container includes an embedded PostgreSQL instance — no external database server is needed. For production use with many concurrent users or large databases, 2 GB is recommended.

No. Bytebase is accessible without a domain via an SSH tunnel — `ssh -L 8080:127.0.0.1:8080 root@<ip>` then `http://localhost:8080`. This works for single-admin use. Once multiple users need simultaneous access, attach a domain: ServOrbit automatically configures nginx and the TLS certificate.

Yes. Gotenberg is stable, MIT-licensed, and used in production by thousands of teams. It isolates each conversion request in a separate Chromium or LibreOffice process — a crash in one conversion does not affect the next. Size RAM according to concurrent requests: allow ~200 MB per concurrent Chromium render.

Yes. Gotenberg uses a full Chromium instance: web fonts (Google Fonts via URL, or local fonts embedded as base64), CSS variables, `@print` media queries, flexbox and grids are all honoured. For local fonts, embed them with `@font-face` and attach the font file in the multipart form.

Gotenberg supports over 20 formats via LibreOffice: DOCX, XLSX, PPTX (and their OpenDocument equivalents ODT, ODS, ODP), RTF, TXT, CSV and more. Send the file as multipart to `/forms/libreoffice/convert` — the output is always a PDF.

No. Gotenberg is stateless: uploaded files and generated PDFs are stored in a temporary directory and deleted immediately after the response. No database, no persistent storage. Your documents only transit through your own infrastructure.

The absolute minimum is 512 MB, but Chromium consumes ~150–250 MB per concurrent request. For typical application use (1–3 concurrent PDFs), 1–2 GB is sufficient. For heavy workloads (10+ concurrent PDFs or large LibreOffice documents), prefer 4 GB or more. Gotenberg does not cache Chromium contexts: each request starts a new process.

FastAPI is async-native with Pydantic validation and auto-generated OpenAPI documentation — ideal for REST APIs and microservices. Django is a full-stack framework with a built-in admin, ORM, and template engine — better suited for monolithic web applications. For a pure API backend, FastAPI is faster to develop and faster at runtime.

Use Gunicorn as the process manager with the UvicornWorker: `gunicorn main:app -k uvicorn.workers.UvicornWorker --workers 4 --bind 127.0.0.1:8000`. The recommended number of workers is (2 × vCPU) + 1. This combines Gunicorn's process management (automatic restart, graceful reload) with Uvicorn's async performance.

Yes. FastAPI has no database dependency. Use SQLite, MySQL, MongoDB, or any database via SQLAlchemy (sync or async) or Motor for MongoDB. The stack installs PostgreSQL 16 for projects that need it — you can ignore it if you start on a different database.

FastAPI automatically generates /docs (Swagger UI) and /redoc (ReDoc) for every endpoint you define. Access https://your-domain.com/docs after deployment. In production, restrict or protect these endpoints with an HTTP basic-auth middleware or a router prefix if the API is not public.

1 GB of RAM is sufficient for a lightweight FastAPI API without a database on the same VPS. Plan for 2 GB with PostgreSQL, and 4 GB if you add Celery and Redis workers. Each Uvicorn/Gunicorn worker uses approximately 50–150 MB depending on the libraries loaded at startup.

Plane is the open-source (AGPL-3.0) self-hosted alternative to Jira and Linear. The feature set is very similar: issues with custom states, cycles (sprints) with burndown charts, modules (epics), wiki pages and analytics views. The key difference: with Plane your data stays on your server, there is no per-seat billing and you fully control data retention. Jira and Linear are the right choice if you don't want to manage a server; Plane is the right choice if you want full control at a fixed cost.

The minimum configuration is 2 vCPU and 4 GB RAM on Ubuntu 24.04 for a team of fewer than 10 people. For a larger team or heavy usage, aim for 4 vCPU and 8 GB RAM. Plane relies on several components (Django, React, Celery, PostgreSQL 16, Redis 7, RabbitMQ and MinIO) — all managed automatically by the ServOrbit template. A custom domain is required for redirect URLs and TLS certificates to work correctly.

Plane includes a native Jira importer: go to Settings → Importers → Jira, enter your Jira instance URL and an Atlassian API token, select the project to import and start. Epics become modules, sprints become cycles, and issues keep their descriptions, labels, priorities and statuses. The import is non-destructive: nothing is modified or deleted in Jira during the migration. A CSV import is also available for migrating from Linear or other tools.

Yes. Cycles are Plane's equivalent of sprints: each cycle has a start date, an end date, a burndown chart and automatic rollover of unfinished issues to the next cycle. The Gantt view is available at the project and workspace level — it displays dependencies between issues as an interactive timeline and lets you drag and drop deadlines directly on the chart to adjust them.

Yes. Install the Plane GitHub App (Settings → Integrations → GitHub) on your repository, then reference issues in your commit messages with the syntax `fix(#123)`, `closes #456` or `ref #789`. Plane will automatically transition the issue based on the keyword used. Pull requests are also linked to issues in the sidebar, and branches created from Plane are named after the issue identifier to facilitate traceability.

FileBrowser starts with admin as the username and admin as the password. Change this password immediately after first login from Settings → Users to secure your instance.

Yes. FileBrowser is accessible via your VPS IP address and the assigned port (8085 by default). For encrypted access from the internet, associate a domain name: the ServOrbit Marketplace recipe then configures the reverse proxy and HTTPS certificate automatically.

Yes. FileBrowser mounts two independent Docker volumes: one for the files it serves (/srv) and one for its SQLite database (/database). Both persist through container restarts, image updates and server reboots.

Yes. From Settings → Users, create as many accounts as needed. Each account has its own accessible directory (home directory) and an optional storage quota. Permissions are managed per directory: a user can be restricted to a subset of the file tree.

FileBrowser provides per-account authentication and per-directory access control. For encrypted traffic, place it behind the HTTPS reverse proxy included in the ServOrbit Marketplace recipe (automatic Let's Encrypt with your domain). Public share links can be time-limited (with an expiry date) or permanent, and are secured per link — a revoked link is no longer accessible.

Go (Gin) Stack is a preconfigured VPS template that automatically installs Go 1.22+ from the official go.dev binary, Nginx, and PostgreSQL 16. It is designed for Go developers who want to deploy a Gin API to production without manually configuring server components.

No. If you compile with CGO_ENABLED=0 GOOS=linux GOARCH=amd64 on your workstation, the resulting binary is 100% static and runs without Go on the server. The template installs Go 1.22+ to let you compile directly on the VPS if preferred, but it is not required for running pre-compiled binaries.

Yes. The template installs the Go toolchain, Nginx, and PostgreSQL — not the framework. Use Echo, Chi, Fiber, or the standard library net/http instead. Gin is recommended in the documentation because of its adoption and zero-allocation router, but the template is framework-agnostic.

1 GB is comfortable for a Gin API without a database. Add 1 GB if PostgreSQL runs on the same VPS. A Gin process typically idles at 15–30 MB; peak memory depends on your handler logic and the size of in-memory caches.

The recommended approach is a systemd unit: ExecStart pointing to your binary, Restart=always for automatic recovery on failure, and EnvironmentFile for secrets. This provides journal logging, resource limits, and dependency ordering (e.g., after PostgreSQL). Alternatively, run your binary inside a Docker container with --restart unless-stopped.

Next.js Stack targets React applications (Next.js), while Nuxt Stack targets Vue.js applications (Nuxt 3). The installed toolchain is identical — Node.js LTS, PM2, Nginx, PostgreSQL — but the frameworks, their build system, and their output files differ.

Yes. Each Next.js application runs as a separate PM2 process on a different port (3000, 3001, 3002…). Nginx routes requests by domain name and proxies to the correct process. A 4 GB RAM VPS can host 3 to 5 lightweight sites simultaneously.

Yes. The template installs Node.js LTS and PM2, which run any version of Next.js including the App Router. The `output: 'standalone'` option in `next.config.js` works identically with the App Router and the Pages Router.

Next.js ISR stores regenerated pages in `.next/cache` on the VPS disk. This cache persists between PM2 reloads (zero-downtime). To avoid clearing it on each deployment, use `pm2 reload` instead of `pm2 restart`. For multiple instances, use a Redis cache handler.

A VPS is preferable when you have high SSR traffic (Vercel bills per invocation), background workers or cron jobs, multiple projects to pool together, or a need for a fixed monthly cost. Vercel remains the best choice for a quick prototype or a lightweight site without auxiliary processes.

Typesense (C++, GPLv3) and Meilisearch (Rust, MIT) are both open-source search engines with typo tolerance and a REST API, available in the ServOrbit Marketplace. Typesense is optimised for strict latency requirements and includes native vector / semantic search. Meilisearch is simpler to configure and preferred for smaller datasets. Both can run on the same VPS — each exposes its own port and its own API key set.

Never include the admin key in the browser. Generate a search-only key with restricted scope via the Typesense API: POST /keys with `{"actions":["documents:search"],"collections":["my-collection"],"description":"front-end key"}` using the admin key as header. The generated search-only key cannot modify collections or access other indexes. Expose it in your JavaScript bundle; keep the admin key server-side only. You can also embed filters to restrict results by tenant or category, which clients cannot override.

Typesense v0.25+ supports `float[]` type fields for storing embeddings alongside text fields. Declare an `embedding` field of type `float[]` in your collection schema, then send your vectors (generated by OpenAI text-embedding-3-small, a local Ollama model, etc.) with each document. For a hybrid query: use `vector_query` with your query vector and combine with `q` for BM25 ranking — Typesense merges the scores using a tunable `alpha` parameter. No separate vector database (Qdrant, Weaviate) is needed for this use case.

Typesense loads its indexes into RAM: plan for roughly 1 MB per 1,000 documents with 3–5 text fields. For a catalogue of 100,000 products, expect ~300 MB of dedicated RAM; for one million documents, ~3 GB. A 1 GB VPS is enough for most projects; move to 2 or 4 GB if you exceed 500,000 documents or enable embedding fields (768–1,536 dimensions per document = 3–6 MB per 1,000 documents). ServOrbit allows online plan changes without reinstallation: data stays on its persistent volume.

Typesense is compatible with the Algolia InstantSearch ecosystem: install `typesense-instantsearch-adapter` (`npm install typesense-instantsearch-adapter instantsearch.js`) and configure the adapter with your instance URL and a search-only key. You get a search bar with suggestions, facets, pagination and term highlighting — without modifying your existing InstantSearch front-end. For React, use `react-instantsearch` with the same adapter. For Vue, use `vue-instantsearch`. The adapter transparently translates InstantSearch calls to the Typesense API.

No. Mailpit is a trap server: it accepts all SMTP connections on port 1025 and stores every message in its local SQLite database without ever forwarding it. No email reaches a real inbox, regardless of the recipient address configured in your application.

In your environment variables or config file, set the SMTP host to 127.0.0.1 and the port to 1025. No authentication or TLS required by default. In Laravel: MAIL_HOST=127.0.0.1, MAIL_PORT=1025, MAIL_ENCRYPTION=null. In Symfony: MAILER_DSN=smtp://127.0.0.1:1025. In Node.js (Nodemailer): host: '127.0.0.1', port: 1025, secure: false. Your application must run on the same VPS as Mailpit to reach the server over the loopback interface.

MailHog has been unmaintained since 2020 and carries an unpatched stored XSS vulnerability (Exploit-DB 50971): an email containing malicious JavaScript can compromise the web interface. Mailpit is its active successor, shipped as the default in Laravel Sail (since v11) and DDEV (since v1.22). It adds full-text search, spam scoring with SpamAssassin rules, HTML compatibility checks per email client, a documented REST API for CI, and POP3 support — all in a Go binary under 50 MB RAM.

Mailpit exposes a REST API on the same port as the web interface (default 8025). Main endpoints: GET /api/v1/messages (list emails with pagination), GET /api/v1/message/{ID} (email detail), DELETE /api/v1/messages (clear inbox), GET /api/v1/search?query=... (full-text search). In PHPUnit (Laravel): use Http::get('http://127.0.0.1:8025/api/v1/messages') to verify an email was sent after an action. In Jest/Vitest: fetch('http://127.0.0.1:8025/api/v1/messages'). No API key required by default.

By default, Mailpit keeps the last 500 messages. When the limit is reached, the oldest messages are automatically deleted to make room for new ones. To change the limit: add the MP_MAX_MESSAGES environment variable to your configuration. Set MP_MAX_MESSAGES=0 for unlimited retention (watch disk space), or an integer value to set a specific message count. Messages are stored in a SQLite database on the mailpit-data volume, making them persistent across container restarts.

Direct Play means the client reads the original file as-is, without conversion: near-zero CPU usage on the server. Transcoding converts the stream on the fly when the client does not support the source format — this consumes CPU. Favor H.264/AAC in MP4 to maximize Direct Play on most devices.

Official free apps exist for iOS, Android, Android TV, Roku and Amazon Fire TV. Kodi has an official Jellyfin plugin. Most modern smart TVs (Samsung, LG) are also supported. The web interface works on any browser without installation.

Space depends entirely on your library. A rough guide: 1 GB per 90-min SD film, 4–8 GB for HD (1080p), 20–50 GB for 4K. Jellyfin itself uses around 500 MB for config and metadata. Media storage is your main constraint.

Jellyfin is 100% free and open source (GPL-2.0): no paid features, no mandatory account, no telemetry. Plex is partially proprietary: some features (offline sync, advanced TV client) require a Plex Pass subscription. Jellyfin installs without an account; Plex requires a server account tied to the Plex service.

Yes. By hosting Jellyfin on a ServOrbit VPS, you get a dedicated public IP and upload bandwidth far higher than a residential connection. Configure Nginx as a reverse proxy with a TLS certificate (Let's Encrypt), and your Jellyfin interface will be accessible from any device or browser worldwide.

Portainer CE (Community Edition) is fully open-source under Apache 2.0 and covers the vast majority of use cases: Docker Compose stack management, per-team access controls, multi-host, live logs and interactive terminal. Portainer BE (Business Edition) adds enterprise features: granular RBAC, Git-triggered deployments and advanced audit logs. On ServOrbit you get Portainer CE — free, unlimited, no licence to manage.

Portainer should only be exposed behind HTTPS with a strong administrator password. It mounts the Docker socket (`/var/run/docker.sock`), which is equivalent to root on the host. On ServOrbit, port 9000 is published only on the loopback — it is never directly reachable from the internet without going through the nginx HTTPS vhost. Never expose Portainer over plain HTTP.

Portainer covers the full Docker surface: standalone containers, images, networks, volumes, Swarm and Kubernetes. Dockge focuses exclusively on Compose stacks and is faster to learn for that specific use case — it is also lighter. Komodo targets multi-server GitOps with a full deployment pipeline. If your goal is a complete visual view of everything Docker manages on a VPS — including containers started outside Compose — Portainer is the broadest tool.

Yes. Install the Portainer Agent on each additional VPS and connect it to your primary instance via the Environments menu. All hosts appear in a unified list and can be managed from one interface. Each VPS continues to run its containers locally — there is no central scheduler. It is a consolidated view of several machines, not a cluster orchestrator.

Open an SSH tunnel from your local machine: `ssh -L 9000:127.0.0.1:9000 root@<vps-ip>`, then navigate to `http://localhost:9000` in your browser. The tunnel forwards the port securely without exposing Portainer to the internet. With a domain name, nginx proxies port 9000 behind HTTPS with an automatically issued certificate and you access the interface directly at your chosen URL.

LibreChat is an open-source, self-hosted chat interface that lets you use multiple AI providers (OpenAI, Anthropic, Google Gemini, Ollama) from a unified UI. Unlike ChatGPT, LibreChat runs on your own VPS: your conversations, API keys and history stay in your MongoDB, with no data sent to third parties.

LibreChat requires a minimum of 2 GB RAM and 2 vCPU (for MongoDB + Node.js). We recommend 4 GB RAM for normal use with multiple users. If you combine LibreChat with a local Ollama model (Llama, Mistral…), plan for at least 8 GB RAM and a recent CPU.

After deployment, log into your LibreChat instance and go to **Settings → API Keys**. You can add a key per provider (OpenAI, Anthropic, Google, etc.) directly from the interface. As admin, you can also configure shared server-level keys in the environment variables, so users don't need to enter their own.

Yes. LibreChat supports custom OpenAI-compatible endpoints. Deploy Ollama on the same VPS (or another), then configure an endpoint pointing to `http://localhost:11434/v1` in `librechat.yaml`. You get a 100% local setup with models like Llama 3, Mistral or Phi-3, with no data sent to cloud APIs.

LibreChat includes a multi-user system. The first account created after deployment becomes administrator. From the **Admin Panel**, you can invite users, set roles (user/admin), control access to models and providers, and disable public registration (`ALLOW_REGISTRATION=false`) for private use. API keys can be shared (admin) or personal (per user).

BookStack is a self-hosted, open-source wiki built on PHP/Laravel. It organizes documentation into **shelves, books, chapters and pages** — a clear hierarchy that makes content immediately navigable. It suits teams that document procedures, APIs or client projects and want to keep that documentation on their own infrastructure without per-seat subscriptions.

BookStack is lightweight: **1 GB RAM** and **15 GB SSD** are sufficient for a team of fewer than twenty people. Memory consumption rises mainly with the volume of uploaded images and attachments. For extensive team documentation or many attachments, **2 GB RAM and 25 GB SSD** are more comfortable. CPU load is low — 1 vCPU fits almost all use cases.

After installation, open your domain URL (configured in your client area). Log in with the **default credentials: email `[email protected]`, password `password`**. Change the password immediately under *Settings → Profile* — anyone who knows the URL can use these defaults before you change them. Then configure your SMTP variables to enable email user invitations.

All three are self-hosted open-source wikis, but with different approaches. **BookStack** enforces a shelves/books/chapters/pages hierarchy — ideal when teams need rigid, navigable structure. **Wiki.js** is more flexible: free page tree, many authentication engines, optional Git storage — suited to technical projects that want to version their docs. **Docmost** is a real-time collaborative editor inspired by Notion — ideal for teams working simultaneously on the same documents. In short: BookStack for structure, Wiki.js for flexibility, Docmost for real-time collaboration.

A BookStack instance is restored from **three elements**: the MariaDB database dump (`mysqldump`), the Docker volume `bookstack_config` (which contains uploads and the Laravel configuration), and the value of the `APP_KEY` variable. **Without APP_KEY**, encrypted content (including session secrets) cannot be decrypted after restoration. Automate a daily `mysqldump` plus a copy of the `bookstack_config` volume to external storage (S3, Backblaze…) and keep your APP_KEY off the server (in a password manager).

Yes — the built-in Open VSX registry covers thousands of popular extensions: ESLint, Prettier, Python, GitLens, Tailwind CSS IntelliSense, and many more. Any extension you install is stored in the persistent volume and stays available after every container restart.

Yes. Your home directory is stored in a named Docker volume (`code-server-data`) mounted at `/home/coder`. All your files, extensions, Git configs and VS Code settings survive restarts and image updates. Only unsaved in-memory state is lost if the container stops unexpectedly.

No. Without a domain, access it through an SSH tunnel: `ssh -L 8080:127.0.0.1:8080 root@<your-ip>` then open `http://localhost:8080` in your browser. Attaching a domain adds HTTPS, which unlocks browser clipboard access, Web Workers, and allows access from networks where the SSH port is blocked.

Code Server runs entirely on your own VPS — you control the data, the runtime and the cost. GitHub Codespaces is a managed cloud service billed per usage (CPU + RAM per hour) hosted on Microsoft infrastructure. Code Server has no session time limit, does not put the environment to sleep, and charges no hourly rate — only the fixed cost of your VPS applies.

Yes. The `codercom/code-server` image can also run directly with `docker run`, or be integrated into an existing `docker-compose.yml` alongside other services. On bare metal, install Code Server directly with the official command `curl -fsSL https://code-server.dev/install.sh | sh` — the binary installs as a systemd service and listens on the same port 8080.

Planka is an open-source, self-hosted Kanban board (MIT licence) inspired by Trello. It lets teams manage their projects with boards, lists and cards on their own infrastructure — no monthly subscription, no data stored on third-party servers.

No. Planka works directly on your VPS IP address (port 80, via nginx). If you want HTTPS access with your own domain, attach it from your client area — ServOrbit configures the TLS certificate automatically.

Use the email address `[email protected]` and the password shown in the **Access** tab of your ServOrbit client area. After logging in, go to **Profile → Edit profile** to replace the default email address and set a personal password.

As many as you need. The MIT licence imposes no user limit. Create accounts from the **Administration → Users** panel and invite them to the projects of your choice.

Planka stores data in two places: the PostgreSQL database (projects, boards, cards, members) and named Docker volumes (avatars, backgrounds, attachments). Back up both: use `docker compose exec postgres pg_dump -U appuser appdb > backup.sql` for the database, and export volumes with `docker run --rm -v <volume>:/data alpine tar czf - /data`.

Dawarich is an open-source web app (AGPL-3.0) that replaces Google Timeline. It stores your GPS history, visualises journeys on an interactive map and shows stats on countries and cities visited — all hosted on your own server, without sharing your location data.

Yes. Dawarich is published behind a domain name: the install asks for the access address before it starts, and the application only answers on the host declared at that point. Use a subdomain of one of your own domains, or the free subdomain that comes with your VPS — either way, ServOrbit creates the DNS record, the reverse proxy and the HTTPS certificate. That is also what makes smartphone sync through OwnTracks or Overland possible, since it needs a reachable address.

Export your history via Google Takeout: in Google Account → Data & Privacy → Download your data, tick 'Location History' and request the archive. Extract `Records.json` and import it in Dawarich via Settings → Import. Processing runs as a background job — large archives take a few minutes.

OwnTracks (iOS and Android, free, open-source) and Overland (iOS) are the two supported clients. Install one, enter your Dawarich server URL in its settings and enable location reporting — Dawarich receives coordinates in real time and maps them automatically.

Dawarich stores data in PostgreSQL and named Docker volumes. Back up the database with `docker compose exec dawarich_db pg_dump -U app dawarich > backup.sql` and export `dawarich_storage` and `dawarich_watched` volumes with `docker run --rm -v <volume>:/data alpine tar czf - /data`. Run these regularly and store backups off the VPS.

Ruby 3.2 from the official Ubuntu 24.04 packages. Rails 7 and Rails 8 both run on 3.2 without any compatibility issue. If you need a different version, install rbenv or asdf alongside the system Ruby and manage multiple versions per project.

Rails Stack installs PostgreSQL by default, the recommended Rails production database. You can install MariaDB or MySQL alongside it, but the template stays configured for PostgreSQL: JSONB columns, full-text search and native Active Record ORM compatibility.

Redis is already installed by the Rails Stack template. Add `gem 'sidekiq'` to your Gemfile, run `bundle install`, create `config/sidekiq.yml`, and set up a systemd unit that runs `bundle exec sidekiq -e production`. Workers and Puma coexist on the same VPS — no separate dyno required.

2 GB of RAM for a single Rails application with PostgreSQL. Add 1–2 GB if you run Sidekiq workers. Each Puma worker uses approximately 200–400 MB in Rails; start with 2 workers and adjust based on observed memory usage with `ps aux` or `htop`.

Yes. Configure a distinct Puma Unix socket per project in `config/puma.rb`, create one Nginx server block per domain, and one systemd unit per Puma process. Each application uses its own PostgreSQL database and Redis namespace — they do not interfere with each other.

Firefly III is an open-source (AGPL-3.0) self-hosted personal and professional finance manager. It tracks transactions, manages budgets by category, generates exportable reports, and can import bank statements — with no subscription and no data shared with third parties.

No. Firefly III works without a domain name. Without an attached domain, you access it via an SSH tunnel: `ssh -L 8080:127.0.0.1:8080 root@<VPS_IP>` then `http://localhost:8080` in your browser. For permanent access from a domain, ServOrbit sets up the Nginx vhost and HTTPS certificate automatically.

Firefly III accepts CSV and OFX files exported from most banks. For European banks, it also supports GoCardless (formerly Nordigen) connectors for automatic sync. The import wizard guides column mapping (date, amount, description) and transaction deduplication.

Firefly III stores data in PostgreSQL. Back up with: `docker compose exec db pg_dump -U appuser appdb > backup.sql`. Schedule this daily via cron and store the file outside the VPS (S3, SFTP) for full protection.

YNAB and Budgea are SaaS tools: they host your data on their servers, charge an annual subscription ($99/year for YNAB, €60/year for Budgea), and may shut down. Firefly III is self-hosted: you install it on your VPS, you own your data, there is no subscription. In exchange, you manage updates and backups yourself.

Budibase is an open-source low-code platform (GPL-3.0, 28,000+ GitHub stars) for building internal tools, dashboards and automations without writing code. Unlike Retool (proprietary SaaS, per-seat pricing) or NocoBase (which starts from the data model), Budibase starts from the interface: choose an existing data source (PostgreSQL, MySQL, REST API…) and compose screens with drag and drop. Self-hosted on your VPS, there is no additional per-user cost and your data stays on your infrastructure.

No. Budibase works without a domain name via SSH tunnel: run `ssh -L 8060:127.0.0.1:8060 root@<your-ip>` then open `http://localhost:8060` in your browser. The connection is encrypted by SSH — no TLS certificate is needed for personal or small-team access. If you want HTTPS access from any device, two options are available: attach your own domain from the ServOrbit client area, or use the free `{app}.{dns_slug}.servorbit-dns.com` subdomain included with every VPS.

As soon as provisioning is complete, open an SSH tunnel on port 8060 (see above) or attach a domain. The first time you open Budibase, a **setup wizard** prompts you to create the administrator account: enter an email address and a password. This account is stored locally in CouchDB and is valid immediately — no email confirmation is needed. You can then invite other users from the organisation settings.

Budibase bundles four services in a single Docker container: the Node.js app server, CouchDB, MinIO and Redis. Idle RAM usage is around **3 GB**, making a VPS with **4 GB RAM the recommended minimum**. For production use with multiple concurrent users or large datasets, **8 GB** provides a more comfortable headroom. If memory usage exceeds what is available, the container may be killed by Linux's OOM killer — choose a slightly over-provisioned VPS rather than the strict minimum.

All Budibase data — app schemas, users, automations, uploaded files — is stored in the Docker volume `budibase-data`, mounted at `/data` inside the container. For a full backup, archive that volume from the host: `docker run --rm -v budibase-data:/data -v $(pwd):/backup alpine tar czf /backup/budibase-$(date +%Y%m%d).tar.gz /data`. The resulting archive contains the complete volume. To restore: stop the Budibase container, extract the archive into a fresh volume, then restart. Schedule this backup in cron and transfer the file to external storage (S3, B2, NFS) for full protection.

Spring Boot Stack is a preconfigured VPS template that automatically installs OpenJDK 21 LTS, Maven, Nginx, and PostgreSQL 16. It is designed for Java developers who want to deploy a Spring Boot application to production without manually configuring server components.

OpenJDK 21 LTS, the default JDK in Ubuntu 24.04 LTS (package `openjdk-21-jdk`). OpenJDK 21 is a long-term support release with Virtual Threads (Project Loom), structured concurrency, and pattern matching for switch. You can install other JDK versions alongside it if needed.

Yes. Maven is installed by the template, but Gradle works on the same JDK. Install it with `apt install gradle` or use the Gradle Wrapper bundled in your project (`./gradlew build`). Spring Boot Stack is designed to host any Spring Boot project regardless of the build tool.

Yes. Run each service on a distinct port (8080, 8081, …), create one systemd unit per service, and add one Nginx server block per service routed by path prefix or subdomain. Services run independently — stopping one does not affect the others.

2 GB for a single Spring Boot application with PostgreSQL. The JVM typically uses 300–500 MB at idle for a standard Spring Boot app; add more if you run multiple services or increase your connection pool. Spring Boot's `-Xmx` flag lets you cap heap usage per service.

Navidrome implements the Subsonic API, the de facto standard for self-hosted music streaming. On Android, Symfonium, DSub and Ultrasonic are recommended. On iOS, Amperfy and iSub work well. These apps connect by entering your instance URL, username and password — your full library is available, with offline playback depending on the client.

Yes. Navidrome does not require a domain name to work. You can access it from your computer via an SSH tunnel: open a terminal and run ssh -L 4533:127.0.0.1:4533 root@your-vps-ip, then go to http://localhost:4533 in your browser. This method is secure and requires no open ports. For permanent mobile access from anywhere, configuring a subdomain with HTTPS remains the most convenient option.

Navidrome is music-only: audio library, playlists, scrobbling, Subsonic API for dedicated music mobile apps. It is very lightweight (under 256 MB RAM) and quick to set up. Jellyfin manages all media — movies, TV shows, music, photos — with a more complete but heavier interface. If your use is exclusively musical and you want dedicated mobile clients (Symfonium, Amperfy), Navidrome is the right fit. If you want a full media library with video, choose Jellyfin.

Navidrome plays all common audio formats: MP3, FLAC, AAC, OGG Vorbis, Opus, M4A, WAV, AIFF and WMA. It reads ID3, Vorbis Comment and iTunes tags directly from files. On-the-fly transcoding to MP3 or Opus is possible for clients that don't support the original format — just install ffmpeg on the server, which ServOrbit configures automatically.

Yes. Navidrome natively manages multiple user accounts, each with their own playlists, favourites, ratings, listening history and scrobbling settings. The administrator account can create and manage other accounts from the admin interface. There is no imposed limit on the number of users — the constraint is the VPS bandwidth and capacity.

Yes. OneDev embeds the server URL in clone links, CI webhook callbacks and OAuth redirect URIs. Without a correctly configured domain, these links point to an unreachable address. You can use a subdomain of your own domain or the free ServOrbit subdomain (`{app}.{dns_slug}.servorbit-dns.com`), which includes HTTPS automatically — no domain purchase needed.

Both are self-hosted Git forges, but OneDev goes further: it integrates a CI/CD engine with a built-in build agent (no separate runner to install), Kanban boards and a package registry in a single container. Gitea is lighter (~200 MB RAM) and requires installing a separate `gitea/act_runner` for CI. Choose OneDev for an all-in-one DevOps platform; choose Gitea for a minimal Git forge with external CI.

Yes. OneDev ships with a local build agent embedded in the `1dev/server` container. As soon as you push a `.onedev-buildspec.yml` file to a repository, a pipeline is queued and executed on this agent — no additional installation. For teams needing parallel builds or specific hardware environments, OneDev allows adding remote agents on other machines, but this is entirely optional.

OneDev's package registry supports Docker/OCI images, npm, Maven/Gradle, NuGet, Helm and others. Each format uses standard tooling (`docker push`, `npm publish`, `mvn deploy`) and the same credentials as your Git instance. Everything is hosted on the same domain and backed up in the same volume — no external registry service needed.

Yes. OneDev includes an import wizard that transfers repositories with their Git history, branches, tags, issues, milestones and pull requests from GitHub, GitLab, Gitea and other platforms. The wizard is accessible from Site Administration → Projects → Import. Note that CI workflows need to be rewritten in `.onedev-buildspec.yml` format, as OneDev is not compatible with the GitHub Actions syntax.

Huginn specialises in web monitoring and data aggregation: its Website Agent extracts content from any page via CSS/XPath selectors, detects changes and triggers actions based on conditions. n8n and Node-RED focus on API-to-API flow automation with a visual editor. Huginn is the right tool for price tracking, web change alerts and RSS aggregation; n8n is better suited to connecting third-party APIs without code.

Plan for 2 GB of RAM minimum — roughly 1 GB for PostgreSQL 16 and 1 GB for the Huginn container, which bundles the web server and the background worker in one process. With more than 50 agents running on tight schedules (every minute), 4 GB is more comfortable. For disk, 15 GB is enough for the application, the database and the event log.

After deploying from the ServOrbit Marketplace, your admin credentials are automatically generated and available in your client dashboard (Marketplace section → your Huginn instance). Log in with username admin and the displayed password. Change this password immediately under Account > Edit after the first login.

In your Huginn instance, click New Agent and choose the type you want (Website Agent, Email Agent, Trigger Agent, etc.). Each agent is configurable via a JSON interface with built-in documentation. On ServOrbit, SEED_EXAMPLE_AGENTS is disabled to keep the instance clean. If you want to see examples, set SEED_EXAMPLE_AGENTS: true in the configuration and restart the container — Huginn will import demo scenarios.

Huginn publishes new images to ghcr.io/huginn/huginn:latest. To update, run docker compose pull && docker compose up -d in your instance directory. Huginn runs database migrations automatically on startup. Always back up the PostgreSQL volume before updating. On ServOrbit, playbook updates are managed from your client dashboard.

No. WhoDB works without a domain via SSH tunnel: run ssh -L 8080:127.0.0.1:8080 root@<vps-ip> from your computer, then open http://localhost:8080 in your browser. For direct access from any browser without a tunnel, attach a domain from your ServOrbit dashboard — or use the free {app}.{dns_slug}.servorbit-dns.com subdomain included with every VPS.

WhoDB supports PostgreSQL, MySQL, MariaDB, SQLite, MongoDB, Redis, ElasticSearch and ClickHouse. You can configure multiple connections at once and switch between them from the left panel without restarting the application.

WhoDB has no user account of its own: it asks you directly for your database connection details. On the home screen, choose the engine from the drop-down list (PostgreSQL, MySQL, Redis…), enter the host, port, username and password of your database, then click Connect. No WhoDB admin account is needed — it is the database access itself that is authenticated.

In WhoDB, go to Settings → AI Provider and enter the URL of your Ollama instance (e.g. http://127.0.0.1:11434 if Ollama is running on the same VPS) or an OpenAI-compatible endpoint. Then choose a model from the list. Once configured, a free-text box appears in the Query tab: type your question in English, WhoDB generates and runs the corresponding SQL query (or Redis command).

Yes. WhoDB encrypts sessions and connection credentials in a persistent Docker volume (/data) on your VPS. This data is never transmitted to a third-party service. To strengthen encryption, set the WHODB_ENCRYPTION_KEY environment variable to a random string of your choice — without it, WhoDB generates a default key. Access to WhoDB itself is protected by your SSH connection or HTTPS if you have attached a domain.

Choose MySQL if your application explicitly requires it — Magento 2, certain Drupal distributions, or PHP plugins that check the engine name (`mysql_get_server_info()` returns "MySQL", not "MariaDB"). For the vast majority of PHP applications (WordPress, PrestaShop, Dolibarr), MariaDB is a drop-in replacement with equivalent performance. When in doubt, check your application's documentation.

No. phpMyAdmin is reachable via an SSH tunnel without a domain name. Open the tunnel from your machine: `ssh -L 8080:127.0.0.1:PORT root@YOUR-IP` (PORT = the number shown in your client area), then open `http://localhost:8080` in your browser. MySQL's port 3306 stays bound to `127.0.0.1` inside the container — reachable from applications hosted on the same VPS.

First create a dedicated user in phpMyAdmin: User accounts → Add user account. Grant it only SELECT, INSERT, UPDATE, DELETE on your application database — never GRANT or SUPER. Then configure your application with: host `127.0.0.1`, port `3306`, database name, user, and password. The root user is reserved for administration — do not use it in your application.

phpMyAdmin is only bound to the local loopback (`127.0.0.1`) — it is not directly accessible from the internet. You access it only through an SSH tunnel, which means only people with an SSH key on the VPS can open it. For production environments, prefer connections through an application user with minimal rights, and access phpMyAdmin only occasionally for administration.

Yes. Both templates deploy their containers in isolated Docker networks and do not interfere with each other. Each stack listens on its own dynamically allocated host port (loopback only) assigned by ServOrbit — no port collision is possible. A 4 GB RAM VPS can comfortably host both for moderate workloads.

HedgeDoc (formerly CodiMD) is an open-source (AGPL-3.0) real-time collaborative Markdown editor. Each note has a unique shareable URL; multiple people edit simultaneously with visible cursors. It supports Mermaid and PlantUML diagrams, LaTeX formulas via MathJax, syntax-highlighted code blocks for 200+ languages, a presentation mode, and one-click export to Markdown, HTML or PDF. On ServOrbit, HedgeDoc is deployed via Docker Compose with PostgreSQL as the database.

Yes. HedgeDoc needs a domain name or subdomain so that shared note links and WebSocket connections are accessible from outside the server. If you do not have a personal domain, the free ServOrbit subdomain included with every app works perfectly: `{app}.{slug}.servorbit-dns.com`, with HTTPS included.

After deployment, open your domain in a browser and click Sign up. The very first registered account automatically becomes the Host (administrator) account. Then disable public registration in Settings → System to prevent unauthorised sign-ups. The admin password is not pre-generated — you choose it during sign-up.

Yes. Mermaid, PlantUML and Vega-lite diagrams render in the live split-screen preview as you type. LaTeX formulas are rendered by MathJax — wrap inline formulas in `$...$` and block formulas in `$$...$$`. Export the entire note to PDF, Markdown or HTML from the main menu with a single click.

HedgeDoc stores its data in two places: the PostgreSQL database (notes, users, sessions) and the `hedgedoc_uploads` Docker volume (uploaded images). Back up both with: `docker compose exec -T database pg_dump -U appuser appdb | gzip > backup.sql.gz` `docker run --rm -v hedgedoc_uploads:/data alpine tar czf - /data > uploads.tar.gz` Automate these two commands with a daily cron job.

Trigger.dev is an open-source (Apache-2.0) background job orchestration platform for TypeScript. It lets you define durable tasks directly in your code — they run with automatic retries, concurrency controls and a real-time dashboard. Unlike BullMQ or a plain cron, Trigger.dev tasks checkpoint their state between steps, so a crash never restarts from scratch. On ServOrbit the full stack (webapp, PostgreSQL, Redis, ElectricSQL, docker-provider, coordinator) deploys with a single compose.

Yes. The magic-link login system generates callback URLs from the `LOGIN_ORIGIN` and `APP_ORIGIN` environment variables. Without a valid domain these links are malformed and authentication fails. On ServOrbit the free `{app}.{slug}.servorbit-dns.com` subdomain provided with every VPS works perfectly — it is available immediately after deployment with built-in HTTPS.

Trigger.dev uses magic-link authentication — no password required. Open `https://your-domain` and enter your email address. The authentication link is printed in the webapp container logs — retrieve it with: `docker compose logs webapp | grep 'magic-link'`. Paste the link in your browser to reach the dashboard. No email server is needed for this first login.

Trigger.dev uses ElectricSQL to synchronize run state in real time between the database and the webapp interface. ElectricSQL requires PostgreSQL logical replication slots, which are only available when `wal_level` is set to `logical`. The ServOrbit compose includes this setting in the PostgreSQL startup command — no manual change needed.

Pull the latest images and restart the stack: `docker compose pull && docker compose up -d`. Trigger.dev runs database migrations automatically at webapp startup. Check the release notes at github.com/triggerdotdev/trigger.dev/releases before each update — some major versions may require additional migration steps.

Automatisch is an open-source self-hosted Zapier alternative. It lets you connect 100+ apps (GitHub, Slack, Notion, Stripe, Google Sheets…) using visual triggers and actions, without writing code. Unlike cloud solutions, all your data stays on your server with no subscription fees or task limits.

Automatisch generates unique webhook URLs from the `HOST` variable. These URLs allow external services (GitHub, Stripe, Typeform…) to send events to your workflows. Without a valid domain, URLs point to `localhost` and are not reachable from the internet. On ServOrbit, the free subdomain included with every VPS works from day one.

After deployment, go to `https://your-domain/auth/sign-up`. Enter your email address and a password to create the first admin account. No confirmation email is sent: you are logged in immediately. It is recommended to create the account right after deployment, before anyone else accesses the URL.

For OAuth integrations (Slack, GitHub, Google Sheets, Notion…), create an OAuth app with the provider and register its credentials in Automatisch. Enter the `CLIENT_ID` and `CLIENT_SECRET` under Settings → Apps. The callback URL is usually `https://your-domain/app/<service>/auth/callback`. Once set, the OAuth connection works via the **Connect** button from the Connections tab.

Pull the latest Docker images and restart the stack: `docker compose pull && docker compose up -d`. Automatisch automatically runs database migrations at startup. Check the release notes at github.com/automatisch/automatisch/releases before each update — some major versions may require specific migration steps.

Kimai is an MIT-licensed open-source time tracking application that you host on your own VPS. It lets you record hours by project, client and activity, set custom hourly rates, generate timesheets and PDF invoices, and produce detailed reports — without a monthly subscription and with no data shared with third parties.

No. Kimai works without a domain via SSH tunnel: `ssh -L 8080:127.0.0.1:8001 root@<your-vps-ip>` then `http://localhost:8080`. For browser access from anywhere, attach a domain from your ServOrbit dashboard or use the free `{app}.{dns_slug}.servorbit-dns.com` subdomain included with every VPS.

Your admin credentials are shown on the app card in the ServOrbit client area right after deployment: login `[email protected]`, auto-generated password. Once logged in, you can change the email address and password from your profile settings.

Yes. Kimai includes a built-in invoice module. Filter your timesheet entries by client and date range, then click **Create invoice** to produce a PDF or HTML document. You can customise the template (logo, colours, payment terms, VAT) from the invoice settings.

All Kimai data lives in three Docker volumes: `kimai_db` (MySQL database), `kimai_data` (uploaded files) and `kimai_public` (avatars). Back them up with `rsync` or SFTP from the host, or use `mysqldump` for a SQL export of the database. Kimai also exports timesheets to CSV and XLSX directly from the interface.

CapRover is an open source PaaS (Platform as a Service) that lets you deploy applications in just a few clicks on your own server. Built on Docker and Docker Swarm, it handles SSL certificates automatically via Let's Encrypt and offers over 280 pre-configured templates (WordPress, Ghost, n8n, Nextcloud…). On ServOrbit, CapRover is available in the Marketplace and provisions in under 60 seconds.

No, a domain name is not required to get started with CapRover. The admin panel is accessible on port 3000 of your VPS immediately after provisioning. A wildcard domain (e.g. ``*.apps.mydomain.com``) is however necessary if you want to expose your deployed apps under dedicated subdomains — this configuration is done from the CapRover panel itself, after installation.

After provisioning the VPS from the ServOrbit Marketplace, navigate to `http://<your-VPS-IP>:3000` in your browser. The login page appears immediately. The default password is `captain42` — change it on first login under Settings → Captain Settings. You can then configure your wildcard domain to access the panel via `captain.mydomain.com`.

CapRover itself uses around 200 to 300 MB of RAM. The minimum for real-world use (CapRover + a few deployed apps) is 2 GB of RAM; ServOrbit recommends the VPS Power plan (8 GB) for the best experience. Keep in mind that each application you deploy through CapRover consumes its own memory — size your plan according to your workload.

Yes, CapRover supports multiple deployment methods: from a Git repository (GitHub, GitLab, Bitbucket) with a webhook for automatic deployments, from a `Dockerfile` or `captain-definition` file, or through the 280+ community templates in one click. It also provides a CLI (`caprover deploy`) for CI/CD pipelines.

No, Homepage has no built-in authentication. It is designed for loopback access (via SSH tunnel) or VPN. To expose Homepage on a public URL, put it behind a reverse proxy that adds HTTP Basic Auth or OAuth, or use Cloudflare Access in front of the instance.

Since version 0.9.0, Homepage validates the HTTP Host header to prevent Host Header Injection attacks. Without this variable you will get an 'Invalid host' error. On a ServOrbit VPS, if you access via SSH tunnel (http://localhost:3000), use HOMEPAGE_ALLOWED_HOSTS="*". If you have a domain (e.g. home.mydomain.com), set it there instead for better security.

Homepage reads Docker metadata through the read-only socket mount (/var/run/docker.sock:ro). Add the following labels to each container you want to appear: homepage.group (the group, e.g. 'Media'), homepage.name (the displayed name), homepage.href (the URL). Homepage detects and displays them automatically without editing services.yaml.

All Homepage configuration lives in YAML files mounted in a Docker named volume (homepage-config), accessible at /opt/stacks/homepage/config/ on your VPS. The main files are: services.yaml (your grouped services), bookmarks.yaml (your favorite links), widgets.yaml (the top widget bar), settings.yaml (theme, language, search engine). Changes apply automatically on the next page reload — no container restart needed.

Homepage uses under 128 MB of RAM for the container itself — no database required. It is one of the lightest applications in the Marketplace. On a ServOrbit VPS, even the entry-level plan is more than sufficient for Homepage. Plan headroom for the other services you want to display in the dashboard (Nextcloud, Jellyfin, etc.) rather than for Homepage itself.

Directus is an open-source headless CMS and data platform (Apache-2.0) that sits on top of any SQL database — PostgreSQL, MySQL, SQLite, MariaDB — and auto-generates a full REST and GraphQL API on top of it. It also provides a no-code administration interface to model content, manage records and set granular permissions. In production, it serves as the back office for web and mobile applications — a front-end queries `/items/<collection>` via REST or GraphQL, and Directus returns the data without a developer having written a single endpoint.

No. Directus works without a domain via an SSH tunnel: `ssh -L 8055:127.0.0.1:<port> root@<vps-ip>` then `http://localhost:8055`. For production front-ends that need to reach the API from the outside, attach a domain from your ServOrbit dashboard — nginx proxies to the Directus container over HTTPS automatically. You can also use the free `{app}.{dns_slug}.servorbit-dns.com` subdomain included with every VPS.

The ServOrbit deployment uses SQLite by default — a single-file database, no external service to manage. This is the recommended starting point for solo use or API testing. For multi-user workloads or heavy read/write loads, edit the Compose file in `/opt/directus/` and switch to PostgreSQL by adding a `postgres:16` container and replacing `DB_CLIENT=sqlite3` with `DB_CLIENT=pg`.

Directus with SQLite (the default ServOrbit configuration) runs comfortably on 512 MB of RAM. For a production project with several simultaneous users or frequent image transformations, 1 GB is recommended. If you add PostgreSQL on the same VPS, plan for 2 GB total. A ServOrbit Cloud S VPS (1 GB RAM) is enough to start; move to Cloud M (2 GB) for team use.

Both sit on top of an existing SQL database and generate an API, but their focus differs. NocoDB is geared towards data entry and organisation: its interface resembles an Airtable-style spreadsheet, ideal for non-technical teams to create and edit records without code. Directus is more developer-oriented: it generates an API consumable by front-end applications and emphasises schema control, automation flows and media management. In practice, NocoDB suits an internal tool or lightweight CRM, while Directus is better as the backend of a public web or mobile application.

No. In standalone mode, Lobe Chat works without a domain via an SSH tunnel: `ssh -L 3210:127.0.0.1:3210 root@your-vps` then `http://localhost:3210`. For a permanent public HTTPS URL, attach a domain from your ServOrbit dashboard or use the free VPS subdomain — nginx proxies Lobe Chat over HTTPS without manual configuration.

In standalone mode (Docker image without a database), API keys are stored in the browser (localStorage) and never leave your device. To centralise them server-side and hide them from browsers, switch to database mode with PostgreSQL — documented in our advanced deployment guide on the blog.

Add the environment variable `ACCESS_CODE=your-secret` when starting the container: Lobe Chat will prompt for this code on every new session. For stronger protection, place a reverse proxy with basic authentication in front of port 3210 (Nginx `auth_basic`, Caddy `basicauth`) or restrict access to specific IPs via the firewall.

Yes. If Ollama is running on the same VPS, set `http://localhost:11434` as the Ollama URL in Settings → Providers → Ollama. Inside the Docker container, use `http://host.docker.internal:11434` if Docker does not have access to the host network. You get a 100% local assistant (Llama 3, Qwen, Mistral…) with no API cost — increase the VPS RAM according to the model size.

In standalone mode (default Docker image), chat history is stored in the browser (localStorage): it is not preserved if you switch browser or device, and a container restart does not erase it. For server-side persistence, use database mode (PostgreSQL + Docker volume) documented in our advanced guide — all conversations are then saved and accessible from any device.

No. The `MASTERKEY` (the `ENCRYPTION_KEY` variable in ServOrbit) is used to encrypt secrets in the PostgreSQL database from the very first boot. Changing it afterwards will make all secrets unreadable and ZITADEL will refuse to start. Store it in a secure password manager. If lost, the only option is a full reinstallation.

No. ZITADEL locks the OIDC `issuer` (your instance URL) at first boot via `ZITADEL_EXTERNALDOMAIN`. This value is stored in the database and included in all JWT tokens issued. Changing it breaks all existing OIDC integrations. If you need a different domain, reinstall the instance from scratch.

Yes. ZITADEL is written in Go and consumes under 100 MB of RAM at idle, compared to 512 MB to 1 GB for Keycloak on JVM. It is therefore suitable for entry-level VPS (2 GB RAM). The PostgreSQL database adds around 50 MB more. A 2 GB RAM VPS is sufficient for team use (10–50 users).

In the ZITADEL console, go to **Instance Settings** → **Login Policy** → enable **Passkeys / WebAuthn**. Users can then register their device (Touch ID, Face ID, FIDO2 key) from **My Profile** → **Passwordless**. Passwordless authentication is available immediately — no additional plugins required.

ZITADEL is natively designed for multi-tenancy. Each **Organization** is an isolated space with its own users, groups, applications and security policies (MFA, SSO, email domain restrictions). Users can belong to multiple organisations with different roles in each. JWT tokens automatically include organisation claims — your applications just need to read them.

No. SiYuan runs on port 6806 and works without a domain name. Open an SSH tunnel from your local machine: `ssh -L 6806:127.0.0.1:<port> root@<vps-ip>` then visit `http://localhost:6806` in your browser. For permanent HTTPS access from the desktop or mobile apps, attach a domain from your ServOrbit dashboard or use the free `{app}.{dns_slug}.servorbit-dns.com` subdomain included with every VPS.

ServOrbit automatically generates an access code (`ADMIN_PASSWORD`) when your VPS is provisioned. This code is passed to SiYuan via the `SIYUAN_ACCESS_AUTH_CODE` environment variable and protects access to the web interface. You can find this code in your ServOrbit credential vault. You can change it later from Settings → Account → Access auth code in SiYuan.

Yes. SiYuan provides native open-source apps for Windows, macOS, Linux, iOS and Android. In the app settings, set the sync endpoint to your VPS HTTPS address and enter your access code. Sync is incremental and end-to-end encrypted. You can also access the full web UI from any browser without installing an app.

SiYuan lets you export individual documents or entire notebooks in several formats. From the context menu of a document or notebook, choose Export then select: Markdown (`.md` files with an assets folder), HTML (standalone page), Word (.docx) or PDF. The Markdown export is readable without SiYuan and can be imported into other tools like Obsidian or Logseq. You can also copy the Docker volume `/siyuan/workspace` directly for a full backup.

SiYuan typically uses under 256 MB of RAM for an active personal workspace. A 1 GB ServOrbit VPS is sufficient for individual use or a team of two to three people. For heavily linked workspaces (thousands of blocks, many graphs) or intensive multi-user use, 2 GB of RAM offers better responsiveness. The SiYuan Docker container ships no extra services — the SQLite database is lightweight and block queries are optimised.

No. Semaphore UI runs on port 3000 without a domain name. Open an SSH tunnel from your local machine: `ssh -L 3000:127.0.0.1:<port> root@<vps-ip>` then open `http://localhost:3000` in your browser. For permanent HTTPS access for your whole team, attach a domain from your ServOrbit dashboard or use the free `{app}.{dns_slug}.servorbit-dns.com` subdomain included with every VPS.

ServOrbit automatically generates an admin password (ADMIN_PASSWORD) when your VPS is provisioned. This password is passed to Semaphore UI via the SEMAPHORE_ADMIN_PASSWORD environment variable. You can find it in your ServOrbit credential vault. Change it immediately after your first login from Profile → Change Password.

No. Semaphore UI uses SQLite, an embedded key-value store written in Go. All data (projects, inventories, tasks, logs) is stored in a single file mounted in a Docker volume. No PostgreSQL, MySQL or Redis is required — the deployment stays a single container.

Semaphore UI supports Ansible, Terraform, OpenTofu and Bash scripts. Each project is configured with its own execution backend. You can manage Ansible playbooks in one project and Terraform plans in another from the same instance, with separate inventories and Key Stores per context.

Yes. Semaphore UI manages multiple user accounts with role-based access control: Viewer (read-only), Task Runner (can trigger tasks) and Admin (full project management). Create accounts from Settings → Users, then assign roles per project. Roles are applied at the project level, allowing you to grant broader rights on a non-critical project than on production.

Yes. Saleor Commerce is deployed with `requireDomain=true` on ServOrbit: the domain is locked at first boot into the dashboard's API URL (`API_URL`) and into `ALLOWED_CLIENT_HOSTS`. These values cannot be changed after launch without recreating the Docker volumes. Attach your domain from your ServOrbit dashboard **before** deploying.

The Saleor admin dashboard is available at the root of your domain: `https://your-domain/`. Credentials are generated automatically at deployment and displayed in your ServOrbit client area. The admin account email is `[email protected]` — change it and the password on first login under Account → Edit profile.

Saleor requires at least one **sales channel** before you can create products. A channel defines the currency, pricing rules and shipping countries. Without a channel, the product creation form is empty and non-functional. Go to Catalogue → Channels → Create channel, fill in a name (e.g. 'Default'), a currency (MAD, EUR…) and a country, then return to product creation.

No. Saleor is a **headless** platform: it provides the GraphQL API and the admin dashboard, but no customer-facing storefront. You bring your own frontend — a Next.js site, a React Native app, or any framework that can consume a GraphQL API. The Saleor community maintains a reference Next.js storefront on GitHub you can fork as a starting point.

The hard minimum is **2 GB RAM** to run the full stack: Django API, Celery worker, PostgreSQL 15 and Valkey 8. In practice, **4 GB is recommended** for production: PostgreSQL needs headroom under concurrent requests, and the Celery worker may process multiple tasks in parallel. With 2 GB, the stack starts but will come under pressure during traffic spikes or large catalog imports.

Flarum is an open-source forum software (MIT licence) written in PHP with a modern SPA frontend (Ember.js). Unlike phpBB or MyBB, the interface updates in real time without page reloads — new posts, notifications and reactions appear instantly. Flarum also includes a Composer extension system that lets you add polls, badges, OAuth SSO and many more features without modifying the source code.

Yes. Flarum locks its public URL (FLARUM_BASE_URL) during the initial installation and cannot change it without recreating the volumes. Attach your domain from your ServOrbit client area before deploying. Without a domain, access is possible via SSH tunnel, but internal links generated by Flarum (invitations, email notifications, shares) will be incorrect.

Flarum automatically creates an administrator account with the credentials flarum (login) and flarum (password). These credentials are publicly known — change the password immediately after the first login at /admin. On ServOrbit, a warning is displayed in your client area until the password has been changed.

From the Flarum admin panel (Administration → Extensions), you can enable available official and community extensions. For unlisted extensions, SSH into your VPS and run `docker exec -it <flarum_container> composer require <vendor/package>` — Flarum reloads extensions on restart. Extensions are persisted in the /data/extensions volume.

Flarum stores its data in two places: the Docker volume /data (assets, installed extensions, storage files) and the MariaDB database. To back up: copy the /data volume directory via rsync or a Docker snapshot, and export the database with `docker exec <db> mysqldump -uflarum -p$DB_PASSWORD flarum > flarum_backup.sql`. To restore: remount the volumes and reimport the SQL dump before restarting Flarum.

Komodo is available as a VPS template in the ServOrbit catalogue and covers Docker container management on single servers as well as multi-server fleets, with built-in GitOps. Unlike Portainer, whose community edition disappears with Portainer 3.0, Komodo remains fully open source. It lets you deploy, monitor and update your stacks from a centralised interface. See our guide on Portainer 3.0 alternatives to choose the right tool for your setup. Activate Komodo on your ServOrbit VPS in a few clicks from the catalogue.

From your ServOrbit client area, go to the Marketplace section, choose the desired application from the catalogue, select your target VPS and confirm the deployment. The template automatically configures the container, persistent volumes and networking. For advanced settings (environment variables, exposed ports), a customisation step is offered before activation. No manual Docker commands are needed: deployment is handled by ServOrbit's VPS template system. Your application is accessible within minutes after activation.

The ServOrbit Marketplace covers deployment and updates of application templates; fine-grained Docker image management (pulling a specific tag, cleaning up unused images, inspecting layers) remains a low-level operation performed via SSH on your VPS. On your root-access VPS, you have the docker image command and docker system prune to free up space. For a full graphical image management interface, templates like Komodo or Dockge are available in the catalogue and provide this functionality.