Marketplace

Choose a Cloud VPS then select the desired template: the environment is installed automatically. Apps that require a domain are served over HTTPS on the address chosen at installation — a subdomain of one of your domains or the VPS's free subdomain; the others have no public address and open through an SSH tunnel.

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 (170 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, published on 127.0.0.1 and relayed over HTTPS by the nginx reverse proxy that ServOrbit sets up on the address chosen at installation. Git over SSH is published on port 2222 — to avoid conflicting with the VPS host SSH on port 22 — but also on 127.0.0.1 only: it is not reachable from the internet. Clone over HTTPS, or go through an SSH tunnel.

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.

Gitea's Git SSH is published on 127.0.0.1:2222 only, so `git clone ssh://git@<your-domain>:2222/<user>/<repo>.git` does not answer from outside. Clone over HTTPS (`git clone https://<your-domain>/<user>/<repo>.git`), or first open an SSH tunnel to the VPS — `ssh -L 2222:127.0.0.1:2222 root@<ip>` — then use `git clone ssh://git@localhost:2222/<user>/<repo>.git`. A Host block in `~/.ssh/config` (HostName localhost, Port 2222) then saves you from specifying the port on every Git command.

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 therefore need an HTTPS address — and ServOrbit sets it up for you: installing Vaultwarden asks for a subdomain of one of your domains or the free subdomain provided with your VPS, then ServOrbit sets up the DNS record, the nginx reverse proxy and the Let's Encrypt certificate. No proxy to configure yourself.

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. They are two separate Marketplace apps, each in its own container, with no port conflict (Ollama on 11434, Qdrant on 6333/6334). Size the RAM accordingly: Ollama alone needs 8 GB minimum for a 7B model, plus Qdrant's memory. You get 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. On ServOrbit, the installation asks you for that address: a subdomain of one of your domains or the free subdomain provided with your VPS — ServOrbit sets up the DNS record, the nginx reverse proxy and the TLS certificate (if your domain's DNS zone is not managed by ServOrbit, first point an A record to the VPS).

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 and English in the ServOrbit recipe, with Arabic available as an add-on), 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, with one setting to change for Arabic. The Docker image bundles Tesseract, and the ServOrbit recipe sets `PAPERLESS_OCR_LANGUAGE=fra+eng`: OCR handles French and English out of the box, not Arabic. To add it, edit the `docker-compose.yml` in `/opt/paperless-ngx` over SSH: change the variable to `fra+eng+ara`, add `PAPERLESS_OCR_LANGUAGES: ara` (which installs the language pack at startup), then run `docker compose up -d`. Mixed-language documents are then processed in all three 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.

Yes, but not necessarily a purchased domain: on ServOrbit, installing NocoBase asks for an address — a subdomain of one of your domains, or the free subdomain provided with your VPS. ServOrbit then sets up the DNS record, the nginx reverse proxy and the Let's Encrypt certificate. Port 13000 is published on 127.0.0.1 only: NocoBase is not reachable at `http://your-vps-ip:13000`, including for internal use.

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.

Yes, an address is required — without having to buy a domain. On ServOrbit, installing Glance asks for a subdomain of one of your domains or the free subdomain provided with your VPS, and ServOrbit sets up the DNS record, the nginx reverse proxy and the HTTPS certificate, which also protects session cookies. Port 8080 is published on 127.0.0.1 only: Glance is not reachable on the VPS IP address.

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 — without having to buy a domain: the installation accepts a subdomain of one of your domains or the free subdomain provided with your VPS. ServOrbit sets up the DNS record, nginx and the Let's Encrypt TLS certificate (if your domain's DNS zone is not managed by ServOrbit, first point an A record 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://127.0.0.1:8080/topic` from your VPS), and any subscriber — mobile app, browser, script — receives it in real time. On ServOrbit, ntfy only listens on 127.0.0.1: for subscribers outside the VPS, expose it yourself at an HTTPS address. Self-hosting gives you unlimited private topics with no rate limits, no third-party account and no monthly fee.

Not to install it: ntfy does not require a domain on ServOrbit, but no URL is assigned to it — its port 8080 is published on 127.0.0.1 only. Scripts and monitoring tools running on the VPS publish directly to `http://127.0.0.1:8080/<topic>`, and the web interface opens through an SSH tunnel (`ssh -L 8080:127.0.0.1:8080 root@<ip>`). However, to publish from another machine, receive on the mobile app or use browser Web Push, the server must be reachable at an HTTPS address — a reverse proxy on your domain, which you configure yourself over SSH.

One line, from the VPS: `curl -d "Job done" http://127.0.0.1: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, Docker entrypoints, Python scripts. From another machine (GitHub Actions, GitLab CI, AWX), replace the URL with the public HTTPS address of your ntfy server, which you configure yourself: the ServOrbit recipe publishes port 8080 on 127.0.0.1 only.

Yes, provided the app can reach your server. The ServOrbit recipe publishes ntfy on 127.0.0.1:8080 only and assigns it no URL: first expose it at an HTTPS address (a reverse proxy on your domain, configured over SSH). The official ntfy apps for Android (F-Droid / Play Store) and iOS (App Store) then let you add that server: enter its URL (e.g. `https://ntfy.your-domain.com`) 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 can be viewed at any time in your client area, from your VPS's installed applications ("Reveal" button), which reads it from your server's `.env` — ServOrbit keeps no copy. Changing it requires a restart with a new key, 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.

The Monica version installed by the ServOrbit recipe (monicahq/monicahq:apache image, 2.x branch) officially supports MySQL and MariaDB only. The recipe uses MariaDB 11, the recommended open-source MySQL-compatible database. PostgreSQL is not supported in this version — 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. The smallest ServOrbit VPS, VPS Start (4 GB RAM), is therefore more than enough for personal use or a small team, and leaves headroom for several AI agents or concurrent users.

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. The smallest ServOrbit VPS, VPS Start (4 GB RAM), is therefore more than enough. If you add Ollama (a separate Marketplace app) on the same VPS for local AI tagging, plan for considerably more: Ollama alone needs 8 GB minimum for a 7B model.

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 does not require a domain on ServOrbit, but no URL is assigned to it: its port 8080 is published on 127.0.0.1 only. Open the status page through an SSH tunnel — `ssh -L 8080:127.0.0.1:8080 root@<ip>` — then `http://localhost:8080`. For a customer-facing status page, you need to proxy Gatus yourself behind nginx with HTTPS and a subdomain like `status.your-domain.com`; internal monitoring and alerting work right after deployment without a domain.

SSH into your VPS: Gatus is installed in `/opt/gatus` and its configuration lives in the Docker named volume `gatus-config`. The Gatus image ships no shell: edit the file through the init container, `cd /opt/gatus && docker compose run --rm gatus-init vi /config/config.yaml`, and add a new block under `endpoints:` with the URL, interval and conditions. Restart with `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 ServOrbit catalogue 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 `/api/docs/<docId>/tables/<tableName>/records`. On ServOrbit, Grist has no public URL (port 8484 published on 127.0.0.1 only): from the VPS, call `http://127.0.0.1:8484/api/docs/…`; from your computer, first open a tunnel `ssh -L 8484:127.0.0.1:8484 root@<ip>` then use `http://localhost:8484/api/docs/…`. 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 or any HTTP client that can reach this port. 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, and that is the default on ServOrbit: the recipe does not publish transfer port 22000 (only the 8384 interface is published, on 127.0.0.1). Syncthing then falls back automatically to global relay servers, and sync works with slightly higher latency. Opening port 22000 in the VPS firewall is therefore not enough for a direct connection: you would also need to recreate the container over SSH with that port published — 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 — but no URL is assigned to Windmill: the interface (port 8000, published on 127.0.0.1 only) opens through an SSH tunnel, `ssh -L 8000:127.0.0.1:8000 root@<ip>`, then `http://localhost:8000`. A domain name over HTTPS, with a reverse proxy you configure yourself, becomes necessary 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 installs without a domain, but ServOrbit then assigns it no URL: its port 5173 is published on 127.0.0.1 only. Access it through an SSH tunnel — `ssh -L 5173:127.0.0.1:5173 root@<ip>` — then `http://localhost:5173`. A domain (with an HTTPS reverse proxy you configure yourself) is still 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. If RAM is tight, you can disable archiving by adding `DISABLE_NEXT_GENERATION_ARCHIVAL=true` to the `environment` section of the `docker-compose.yml` in `/opt/linkwarden` (over SSH — not from the client area), then `docker compose up -d`, 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, add the `DISABLE_NEW_SIGN_UPS=true` variable to the `environment` section of the `docker-compose.yml` in `/opt/linkwarden`, over SSH (it is not editable from the client area), then run `docker compose up -d`. 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`.

Yes, outside the reseller offer, which is shared cPanel/WHM hosting without VPS. You order VPS from your client area at the public price — there is no wholesale price and no volume discount —, deploy a Marketplace app on them (Mattermost, Nextcloud…) or your own stacks using your scripts or Docker images, then deliver them to your clients at the price you set. The VPS is unmanaged: installation, maintenance and support for your clients remain in your hands. To discuss it, contact our sales team at [email protected].

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

No. Mealie does not require a domain on ServOrbit, but no URL is assigned to it: its port 9000 is published on 127.0.0.1 only, not on the VPS IP address. For personal use, open it through an SSH tunnel (`ssh -L 9000:127.0.0.1:9000 root@<ip>`, then `http://localhost:9000`). Internet access with a valid TLS certificate requires a domain and a reverse proxy, which you configure yourself.

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) — orchestrated with Plane's official Docker Compose deployment (Plane is not yet offered for order on the ServOrbit Marketplace). 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 does not require a domain on ServOrbit — but no URL is assigned to it: its port (8085 by default) is published on 127.0.0.1 only, not on the VPS IP address. Access it through an SSH tunnel: `ssh -L 8085:127.0.0.1:8085 root@<ip>`, then `http://localhost:8085`. For encrypted access from the internet, the HTTPS reverse proxy is yours to configure: ServOrbit does not set it up for this app.

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.

Yes, on VPS you order from your client area — the ServOrbit reseller offer itself is shared cPanel/WHM hosting, without VPS. Deploy Vikunja from the Marketplace, or install Plane yourself: Plane is not offered for order on the Marketplace. You then deliver the tool to your clients under your own domain and set your price freely, as VPS are billed at the public price, with no wholesale price. For any question, contact our sales team at [email protected] or open a ticket from your client area.

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 does not require a domain on ServOrbit, but no URL is assigned to it and no nginx is set up: Planka listens on port 1337, published on 127.0.0.1 only. Access it through an SSH tunnel — `ssh -L 1337:127.0.0.1:1337 root@<ip>` — then open `http://localhost:1337`. HTTPS access on your own domain is yours to configure (reverse proxy and TLS certificate).

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.

Yes, you can deploy Mattermost or Rocket.Chat on a dedicated VPS for each client and include them in your offering. Both are available as VPS templates in the Marketplace, which speeds up deployment. VPS are ordered from your client area at the public price: they are not part of the reseller offer, which is shared cPanel/WHM hosting. For architecture or billing guidance, contact our sales team at [email protected].

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.

Docmost is available as a VPS template in the ServOrbit Marketplace: you can deploy one instance per client on a dedicated VPS and serve it under your own subdomain. You manage that subdomain and the Docmost interface yourself; nothing on the ServOrbit side applies automatically to applications deployed on a VPS. VPS are ordered from your client area at the public price: they are not part of the reseller offer, which is shared cPanel/WHM hosting.

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 (`/opt/huginn`). Huginn runs database migrations automatically on startup. Always back up the PostgreSQL volume before updating. On ServOrbit, the Marketplace installs and uninstalls the application; updates are done this way, over SSH.

Yes. Vaultwarden is available as a VPS template in the Marketplace: order a dedicated VPS, deploy Vaultwarden on it under your own domain and present it to your clients under your brand. Each client organisation gets its own Vaultwarden instance or organisation, keeping vaults isolated. The VPS is billed at the public price, with no wholesale price, and you set your own price freely. For any question, contact our sales team at [email protected].

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.

Yes, Open WebUI and LibreChat are available as VPS templates in the ServOrbit.com Marketplace. Each deployment runs on a dedicated VPS with root access, which you order from your client area: you can customise the interface, manage user access and connect your own API keys. Conversations and history stay on that VPS; only the requests sent to an external AI provider (OpenAI, Anthropic…) leave the machine. For tailored guidance, request a quote via the contact form.

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.

Yes: on a ServOrbit VPS, you can deploy monitoring tools from the Marketplace — Grafana, Uptime Kuma and Gatus are available there as VPS templates — and give your clients access to them under your own domain. The VPS is ordered from your client area, outside the reseller offer, which is shared cPanel/WHM hosting; its root access gives you control over the machine and the installed applications, including their look when the tool allows it to be customised. Manage per-client access by creating separate organisations or workspaces depending on the chosen tool.

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…). CapRover is not yet offered for order on the ServOrbit Marketplace; you can install it yourself on your ServOrbit VPS by following its official documentation.

No, a domain name is not required to get started with CapRover. The admin panel is accessible on port 3000 of your VPS as soon as its installation is complete. 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.

Once CapRover is installed on your VPS, navigate to `http://<your-VPS-IP>:3000` in your browser. The login page appears immediately. CapRover asks for no username, only a password: the one set at install time; when the installation goes through the ServOrbit Marketplace, it is generated for your server and you will find it in the Applications section of your client area (“Reveal” button). Then configure your wildcard domain to access the panel via `captain.mydomain.com`, enable HTTPS for the dashboard, and change the password if you wish.

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 in the Docker named volume homepage-config, mounted at /app/config inside the container (the app is installed in /opt/homepage on your VPS). To edit them over SSH: `cd /opt/homepage && docker compose exec homepage vi /app/config/services.yaml`. 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. The smallest ServOrbit VPS, VPS Start (4 GB RAM), therefore covers these needs, team use included.

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.

As a ServOrbit reseller, you order a VPS on your client's behalf from your Agency Area, install Chatwoot via the marketplace or manually, then freely set your resale price. The VPS order is paid from your agency wallet, at the public price plus your margin, if any — there is no wholesale price; you handle client billing with your own tool (Dolibarr, Stripe…). To keep things simple, you can create your client's account from your Agency Area so that they manage their own access.

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. The smallest ServOrbit VPS, VPS Start (4 GB RAM), is therefore more than enough for individual use or a team of two to three people, including heavily linked workspaces (thousands of blocks, many graphs) that call for around 2 GB. 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, put Semaphore UI behind an HTTPS reverse proxy, with a domain or subdomain pointing to your VPS. Semaphore UI is not yet offered for order on the ServOrbit Marketplace: these instructions apply to an installation you carry out yourself on your VPS.

Semaphore UI is not yet offered for order on the ServOrbit Marketplace. When the installation goes through the Marketplace, ServOrbit automatically generates an admin password (ADMIN_PASSWORD) at provisioning, passes it to Semaphore UI via the SEMAPHORE_ADMIN_PASSWORD environment variable, and you can find it in your ServOrbit credential vault; if you install Semaphore UI yourself on your VPS, set this variable in your Docker configuration. Either way, 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's 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. Point your domain to your VPS **before** deploying. Saleor Commerce is not yet offered for order on the ServOrbit Marketplace: you can install it yourself on your VPS.

The Saleor admin dashboard is available at the root of your domain: `https://your-domain/`. When the installation goes through the ServOrbit Marketplace, credentials are generated automatically at deployment and displayed in your client area (Saleor Commerce is not yet offered for order there; if you install it yourself, they are the ones you set). 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. The installation therefore asks you for an address: a subdomain of one of your domains or the free subdomain provided with your VPS — ServOrbit sets up the DNS record, nginx and the HTTPS certificate. Pick the final address from the start: changing it later would break the internal links generated by Flarum (invitations, email notifications, shares).

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. Environment variables and ports are not editable from the client area: to adjust them after installation, edit the app's `.env` file or `docker-compose.yml` in `/opt/<app>` over SSH, then run `docker compose up -d`. The deployment itself needs no manual Docker commands: it is handled by ServOrbit's VPS template system. Your application is accessible within minutes after activation.

The ServOrbit Marketplace installs and uninstalls application templates; their updates, like fine-grained Docker image management (pulling a specific tag, cleaning up unused images, inspecting layers), are done 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.

Qdrant (Rust) focuses on pure vector similarity search with payload filters — schema-free and without built-in vectorization. Weaviate (Go) adds a schema layer and built-in vectorizer modules (text2vec-openai, text2vec-cohere, img2vec) that call embedding models at ingest time, plus a GraphQL API and native multi-modal support. Choose Qdrant for raw performance on pre-embedded vectors; choose Weaviate when you want the database to handle vectorization automatically, or when you need GraphQL query syntax or multi-modal collections.

Weaviate itself uses 400–600 MB at idle. Total memory scales with your index: the number of objects, the vector dimension and the HNSW parameters are the main factors. A 4 GB VPS comfortably handles collections of a few hundred thousand objects with 1536-dimensional vectors (OpenAI or Cohere embeddings). For millions of objects, enable binary quantisation (up to 32× memory reduction) or use an 8 GB VPS.

Weaviate is bound to `127.0.0.1` — it has no public address by default. To reach it from your workstation, open an SSH tunnel: `ssh -L 8080:127.0.0.1:<port> root@<vps-ip>` (replace `<port>` with the port shown on your app card in the client area). The REST and GraphQL APIs then respond at `http://localhost:8080`. You can also call Weaviate directly from an application running on the same VPS, without a tunnel, via `http://127.0.0.1:8080`.

Weaviate exposes both. The GraphQL API is recommended for similarity queries (`nearVector`, `nearText`, `nearImage`) and object retrieval with filters — this is what LangChain and LlamaIndex use. The REST API is more convenient for schema management (`/v1/schema`), bulk import (`/v1/batch/objects`) and CRUD operations on individual objects. Both are available on port 8080; port 50051 is reserved for the gRPC protocol, used by the official Go, Python and TypeScript clients for higher throughput.

By default, this Weaviate deployment uses `DEFAULT_VECTORIZER_MODULE=none`: you supply your own vectors on every import. To enable a cloud module, you need to add the corresponding environment variables to the container — they are not editable from your client area: Weaviate runs in a `weaviate` container started with `docker run`, which you recreate over SSH with the variables you need, keeping its ports and its `weaviate_data` volume. Example for text2vec-openai: add `-e ENABLE_MODULES=text2vec-openai` and `-e OPENAI_APIKEY=<your-key>`. Weaviate will then call the OpenAI API on every import or `nearText` query. See the Weaviate documentation for the full list of available modules and their variables.

No. CPU-only inference works out of the box via Ollama. A modern server CPU handles a 7B Q4_K_M model at 2–5 tokens/sec — usable for document Q&A where accuracy matters more than speed. For faster inference on larger models, a GPU-equipped VPS accelerates throughput 10–30×.

For general document Q&A on CPU: `qwen2.5:7b` or `mistral:7b` (Q4_K_M, ~4–5 GB). For longer legal or technical documents: `llama3.1:8b`. For a lightweight setup on 8 GB RAM: `qwen2.5:3b` (~2.3 GB). For embeddings: `nomic-embed-text` (270 MB) provides strong semantic retrieval quality.

Yes. Set the `OPENAI_API_BASE` environment variable to `https://api.openai.com/v1` and provide your `OPENAI_API_KEY`. The RAG pipeline will then use OpenAI for both embeddings and generation, while your documents remain indexed locally on the VPS.

Yes. PrivateGPT ships with an embedded vector store that persists your indexed chunks on disk in the `private-gpt-data` Docker volume. You do not need to run a separate Qdrant or ChromaDB container. The index survives container restarts.

PrivateGPT is bound to `127.0.0.1` — it has no public address by default. Open an SSH tunnel: `ssh -L 8080:127.0.0.1:<port> root@<vps-ip>` (replace `<port>` with the port shown in your ServOrbit client area), then navigate to `http://localhost:8080/ui`. For a permanent HTTPS URL, attach a domain in your client area.

No. Airflow is a workflow orchestrator, not a compute engine. It schedules and monitors Python tasks on CPU — the tasks themselves can call GPU APIs or Spark clusters, but Airflow only needs standard RAM and CPU.

LocalExecutor runs tasks in parallel as local processes on the same server as the scheduler — ideal for hundreds of tasks per day on a single VPS, no Redis required. CeleryExecutor distributes tasks across remote workers — needed for thousands of concurrent tasks or multiple servers. For typical use on a ServOrbit VPS, LocalExecutor is the recommendation.

In LocalExecutor mode, expect 1–2 GB of RAM at idle (webserver + scheduler + PostgreSQL). For Python DAGs loading pandas or large files, plan for 4 GB to have headroom for task processes. CeleryExecutor mode — with workers and Redis — requires 4–8 GB depending on the number of workers.

Open an SSH tunnel: `ssh -L 8080:127.0.0.1:<port> root@<vps-ip>` (replace `<port>` with the port shown in your client area), then open `http://localhost:8080`. For a permanent public URL, attach a domain in your client area — nginx will reverse-proxy to Airflow and provision a TLS certificate automatically.

Yes. Build a Docker image derived from `apache/airflow:3.3.0` with a `requirements.txt` file: add a `FROM apache/airflow:3.3.0` line and then `RUN pip install --no-cache-dir your-package`. Use this image in your compose instead of the official image. This is the recommended method — installing packages at runtime is slow and not reproducible.

No. Verdaccio listens on port 4873 internally and is accessible via an SSH tunnel without any domain: `ssh -L 4873:127.0.0.1:<port> root@<vps-ip>`. For permanent team or CI access, attach a domain from your ServOrbit dashboard — nginx will proxy it over HTTPS automatically.

Yes. Verdaccio implements the full npm registry protocol. Yarn and pnpm both support custom registry configuration: the `--registry` flag on the command line, `registry=` in `.npmrc`, or `npmRegistryServer:` in `.yarnrc.yml` for Yarn 2+. No additional plugins are needed.

No. Verdaccio proxies npmjs.org by default: any request for a package not in the local registry is forwarded to the public registry, cached, and served. You keep using all public packages normally, and your private packages stay on your VPS.

Pull the new image and restart the container: `docker compose pull && docker compose up -d`. Verdaccio stores all packages in the `verdaccio-storage` Docker volume, which is preserved across image updates — no data migration needed.

First create an account with `npm adduser --registry https://your-verdaccio.com`, then log in with `npm login --registry https://your-verdaccio.com`. In your package, set `"name": "@your-org/package-name"` in `package.json` and ensure your `.npmrc` contains `@your-org:registry=https://your-verdaccio.com`. Publish with `npm publish`. Scoped packages under `@your-org/*` will be automatically routed to your Verdaccio registry.

Unleash is an open-source (Apache-2.0) feature flags platform that lets you enable or disable features in your application in real time, without redeployment. In practice, you wrap a new feature behind a toggle in your code, and the Unleash UI decides whether that toggle is active for each user. You can deploy code to production confidently, activate the feature progressively (5 %, 20 % rollout…), target a specific user segment, or trigger an immediate kill switch if something goes wrong — without touching the code or triggering a deployment pipeline.

Unleash provides official SDKs for Node.js, Python, Java, Go, .NET (C#), Ruby, PHP, iOS (Swift) and Android (Kotlin). The community also maintains SDKs for Rust, Elixir, Clojure and other languages. All official SDKs implement the same evaluation algorithm and evaluate flags locally in your application — with no network round-trip per request, for zero added latency.

In the Unleash UI, open your flag and click **Add strategy** in the target environment (e.g. `production`). Select the **Gradual rollout** strategy and set the slider to the desired percentage (e.g. 10 %). Unleash uses a hash of the `userId` to ensure the same user always gets the same result — the same 10 % sees the feature on every visit. You can progressively increase this percentage from the UI without touching your code or redeploying your application.

Pull the new image and restart the containers: `docker compose pull && docker compose up -d`. PostgreSQL database migrations run automatically on startup of the new version — no manual intervention needed. The PostgreSQL volume (`unleash-db`) is preserved across updates, so no data (projects, flags, strategies, metrics) is lost. Check the Unleash changelog on GitHub before each major update for potential SDK API breaking changes.

Environment variables require a full application redeployment to change. Unleash evaluates flags at runtime via the SDK: you change a toggle in the UI and all running instances of your application pick it up within seconds — without touching the binary, without redeployment, without downtime. In addition, Unleash enables complex rules that are impossible with environment variables: gradual rollout by percentage, targeting by userId, pricing plan, country. And every change is tracked in the audit log with the author and timestamp.

Blinko is an open-source AI-powered note-taking app (GPL-3.0). It organises your notes as atomic cards — one idea per card — with built-in full-text and semantic search. By connecting an Ollama model or any OpenAI-compatible endpoint, you can ask natural-language questions across your entire note history. Everything stays on your VPS, with no cloud account or subscription.

No. Blinko publishes its port on localhost only (127.0.0.1), so no domain is required. Without a domain, open an SSH tunnel from your local machine: `ssh -L 1111:127.0.0.1:<port> root@<vps-ip>` (the actual port is shown in your ServOrbit client area, not necessarily 1111), then open `http://localhost:1111` in your browser. For permanent access from multiple devices, attach one of your domains from your dashboard — nginx proxies the container over HTTPS with automatic certificate renewal — or use the free `{app}.{dns_slug}.servorbit-dns.com` subdomain included with every VPS.

Blinko and its PostgreSQL database together consume approximately 400–600 MB RAM at rest. A 1 vCPU / 1 GB RAM VPS is sufficient for a single-user or small-team instance. If you plan to enable AI search with an Ollama sidecar on the same VPS, plan for at least 4 GB RAM depending on the model size (7B models typically require 6–8 GB). For external OpenAI endpoint usage only, 1–2 GB RAM remains sufficient even with semantic search enabled.

In Blinko, go to Settings → AI. Enter the URL of an OpenAI-compatible endpoint and the model name. Two options: (1) Use the OpenAI API directly — enter `https://api.openai.com/v1`, your API key and a model name (e.g. `gpt-4o-mini`). (2) Keep everything on your server — deploy an Ollama instance on the same VPS from the ServOrbit Marketplace (AI and Machine Learning category), then point Blinko to `http://localhost:<ollama-port>/v1` with the downloaded Ollama model name (e.g. `llama3.2`). Once configured, Blinko indexes your existing notes as vectors and the search bar understands natural-language queries.

All Blinko data lives in two Docker volumes: `blinko-db` (PostgreSQL database) and `blinko-uploads` (attachments and uploaded files). To back up: (1) Export the database with `docker exec blinko-db-1 sh -c 'pg_dump -U blinko blinko' > backup_$(date +%Y%m%d).sql`. (2) Copy the attachments folder via SFTP. To restore on a new VPS: start the containers, then import the dump with `docker exec -i blinko-db-1 psql -U blinko blinko < backup.sql` and reload the attachments. Automate with a daily cron on the VPS.

No, RustDesk can operate entirely without internet access when both machines are on the same local network, or when a relay server (`hbbs`/`hbbr`) is deployed on your own VPS. In a self-hosted setup, the rendezvous server (`hbbs`) and relay server (`hbbr`) are installed on your infrastructure, and clients are configured to point to those addresses. Clients can then connect directly to each other (P2P connection) if the network topology allows, or route through your private relay. No data passes through RustDesk's public servers when your own infrastructure is properly configured.

Khoj is an open-source personal AI assistant (AGPL-3.0) that you self-host on your own VPS. It automatically indexes your Obsidian notes, PDF documents and emails so you can ask natural language questions about your private knowledge base. It also includes autonomous agents that can search the web and aggregate external sources.

Yes, an address is required — but not necessarily a purchased domain. Khoj uses it for authentication URLs, sharing links and scheduled task callbacks. At installation, choose a subdomain of one of your domains or the free subdomain provided with your VPS: ServOrbit sets up the DNS record, nginx and the HTTPS certificate. One exception: if your domain's DNS zone is not managed by ServOrbit, first point an A record to your VPS IP.

ServOrbit creates an initial admin account with the email [email protected] and a random password shown in your client area. Log in to the web interface at your domain, go to Settings to configure a LLM (Ollama or OpenAI), then create your own user account if needed.

Khoj is compatible with Ollama (local models like Llama 3, Mistral or Qwen), OpenAI and Anthropic. For 100% local use without API costs, install Ollama on the same VPS or a network machine and configure it in Settings → LLM. For better performance, an OpenAI key (gpt-4o-mini) works very well.

Khoj requires at least 4 GB of RAM and 2 vCPUs. The service loads embedding models at startup and uses PostgreSQL with pgvector for vector storage. Plan for 20 GB of disk as a baseline, plus extra space depending on the volume of documents to index. Khoj does not require a GPU: LLM inference is delegated to your configured LLM.

ArchiveBox is an open-source (MIT) web archiving tool that lets you save web pages, articles, videos and media directly to your VPS. Instead of relying on third-party services like Pocket or Archive.org, you store your archives in your own infrastructure: each URL you submit generates a snapshot in HTML, PDF, screenshot PNG, WARC and plaintext. You can then retrieve those pages even if they've disappeared from the web, share them with your team via signed links, or use them as digital evidence in a legal context.

ArchiveBox listens on port 5797 (Daphne ASGI server) internally, bound to the loopback interface only (127.0.0.1) — it is not directly exposed to the internet. To access the interface from your browser, open an SSH tunnel: `ssh -L 5797:127.0.0.1:<exposed-port> root@<vps-ip>` then navigate to `http://localhost:5797/`. The admin interface is at `/admin/`. For permanent access without a tunnel, attach a domain or subdomain from your ServOrbit client area: nginx will proxy traffic to HTTPS automatically.

For each URL submitted, ArchiveBox can simultaneously produce: a full HTML mirror via wget (with CSS/JS/image assets), a self-contained single-file HTML capture via SingleFile, a full-page PNG screenshot, a PDF (Chromium-rendered), an ISO 28500-compliant WARC file with CDX index, a JSON of the final JavaScript DOM, and plaintext indexed for full-text search. yt-dlp is also integrated for video archiving (YouTube, Vimeo, Twitter, etc.). Each extractor can be enabled or disabled globally in the `.env` file or per URL from the web interface.

No, ArchiveBox does not require a domain to function. By default, the container listens on the loopback (127.0.0.1) and is accessible by opening an SSH tunnel from your workstation. This is sufficient for solo use. If you want permanent access from any browser or from your team, you can attach a subdomain from your ServOrbit client area: the nginx server is configured automatically and a Let's Encrypt TLS certificate is provisioned. Once the domain is active, remember to update the `ARCHIVEBOX_CSRF_TRUSTED_ORIGINS` variable in your compose to avoid CSRF errors.

The update takes two commands from your VPS: `docker compose pull` to download the new image, then `docker compose up -d` to recreate the container with the new version. ArchiveBox automatically runs Django migrations on startup — your archive data in the `archivebox-data` volume is fully preserved. Check the release notes on the GitHub repository before each major update for any schema migrations or configuration changes. In case of issues, the `archivebox-data` volume is independent of the container: you can roll back to the previous image with `docker compose up -d --image <version>` without losing your archives.

Teable is an open-source alternative to Airtable (AGPL-3.0). Like Airtable, it offers grid, kanban, gallery and form views for organizing data visually. The key difference is that Teable stores every table directly in PostgreSQL — giving you full SQL access, complete data portability and no cost per user or row. On ServOrbit, Teable runs on your own VPS: your data never leaves your infrastructure.

After deployment, navigate to the URL provided by ServOrbit. Teable shows a registration page: the first account you create becomes the workspace owner. There is no preset admin account — you choose your credentials at that first registration. Once logged in, you can invite collaborators from the workspace settings and assign their roles (viewer, editor or owner).

Every Teable table automatically exposes a REST API. From the Teable interface, open Settings → API Tokens to generate an access token. The API follows REST conventions (GET, POST, PATCH, DELETE) on `/api/table/{tableId}/record`. You can connect this API to automation tools like n8n or Zapier, or call it directly from your backend application to read or write data in real time.

The three tools are complementary. NocoDB connects to an existing PostgreSQL or MySQL database and wraps it in a collaborative spreadsheet UI — ideal if you already have a schema to visualize. Grist uses a Python-formula document model, more powerful for analysis. Teable creates its own PostgreSQL tables from scratch and focuses on real-time visual collaboration — it is the closest to the Airtable experience. Choose NocoDB to wrap an existing database, Grist for analysis, Teable to build a new collaborative base.

Teable requires at least 2 GB of RAM to run the three containers (PostgreSQL 15, Redis 7 and the application server). For comfortable use with multiple collaborators, 4 GB of RAM and 2 vCPUs are recommended. Plan for at least 20 GB of SSD disk for PostgreSQL volumes and uploaded assets. Teable does not require a GPU — all operations run on the CPU.

Yes. Order VPS from your client area and deploy open-source collaboration solutions such as Mattermost or Nextcloud on them via the Marketplace, without depending on Microsoft licences. These VPS are billed at the public price and are not part of the reseller offer, which is shared cPanel/WHM hosting: you re-bill them to your clients at the price you set. See the reseller offer page or contact us at [email protected] for tailored guidance.

Teable offers partial compatibility with the Airtable API. Importing via the Airtable REST API is natively supported in Teable: provide your Airtable API key and base ID, and Teable reconstructs the tables, fields, and records. Common field types (text, number, date, checkbox, single and multiple select, linked records) are mapped automatically. However, Airtable features without a direct equivalent in Teable are not imported: automations, interfaces, and scripts. Attachments are downloaded and stored locally on your ServOrbit VPS. For a base with fewer than 50,000 records, the full import typically takes less than 10 minutes. The Teable template is available at /applications/bases-de-donnees/teable. After migration, check filtered views and calculated formulas — their syntax differs slightly between the two tools.

Plane and Kaneo address different needs. Plane is a full-featured project management tool, competing with Asana and Jira: it offers cycles (sprints), modules (epics), a roadmap, multiple views (list, kanban board, calendar, spreadsheet), time tracking, analytics reports, and a rich API. It is the right choice for product or software teams managing complex backlogs. Kaneo is a minimalist kanban-oriented tool: columns, tasks, labels, assignees — that is it. Its interface is deliberately clean, onboarding is instant, and its server resource usage is very low (less than 256 MB of RAM). It is the right choice for a small team or solo project that wants a visual board without the complexity of a full-featured tool. On ServOrbit, Kaneo is available on VPS from /applications/collaboration/kaneo; Plane is not yet offered for order on the Marketplace, but you can install it yourself on your VPS. If you are unsure, start with Kaneo — it is easier to migrate to Plane later than to go back.

Penpot is available in the ServOrbit marketplace as a ready-to-deploy application. From your VPS space, select Penpot, choose your target VPS (minimum 4 GB RAM recommended) and launch the installation with one click. ServOrbit automatically configures Docker, the nginx reverse proxy and TLS certificate. You get a private Penpot instance with your own user accounts, ideal for replacing Figma without a monthly subscription.

Headscale is an open source coordination server compatible with Tailscale that lets you manage your own private mesh network without relying on a third-party cloud service. Available in the ServOrbit marketplace, it installs with one click on your VPS and gives you full control over network access between your machines. It is the ideal solution for securing access to your internal services (databases, back-offices) without exposing public ports.

Yes. Flowise is available in the ServOrbit Marketplace (Automation category): you can deploy it on a VPS directly from its page. LangFlow and n8n are also offered there if you prefer another approach to building AI agent workflows.

Yes. BookStack is open-source software released under the MIT licence — deploying it, including for your clients, incurs no licence cost. Each instance runs on its own VPS, isolated from the others, and is deployed from the BookStack template in our Marketplace. VPS are ordered from your client area at the public price — they are not part of the reseller offer, which is shared cPanel/WHM hosting — and you freely set the price you charge your clients.

Baserow is an open-source (MIT) no-code platform that lets you create visual databases without writing SQL. You organise your data in tables and fields (text, number, date, file, formula…), invite your team, switch between multiple views (grid, kanban, gallery, form) and expose every table via an auto-generated REST API. Think Airtable, but hosted on your own VPS, with no row limits and no per-seat pricing.

No, Baserow does not require a domain name to get started. Baserow is not yet offered for order on the ServOrbit Marketplace; if you install it yourself on your VPS, you can reach it via the server's IP address, then, for a custom HTTPS URL, point a domain or subdomain to your VPS and put Baserow behind a reverse proxy with a TLS certificate.

The Baserow all-in-one container (Django, Celery, Redis and PostgreSQL) starts at roughly 700 MB of RAM at idle. A 2 GB VPS handles a small team (5–10 users) comfortably. For larger workspaces, sustained API traffic or heavy file uploads, 4 GB of RAM and 2 vCPUs are recommended. No GPU is required.

When you first access your Baserow instance, a registration page is displayed. Enter your email address and choose a password: the first account created becomes the workspace administrator. This page is shown only once — as soon as one account exists, subsequent visitors see the standard login page. Create your account immediately after Baserow is installed.

Log in to your VPS via SSH and run: ```bash docker compose pull && docker compose up -d ``` Baserow applies database migrations automatically on startup. Your data in the `baserow-data` volume is preserved across versions. Check the Baserow GitHub releases page before updating for new features and any migration notes.

Pocket ID is not yet offered for order on the ServOrbit Marketplace; you can install it yourself on an Ubuntu 24.04 VPS with Docker. Have a domain ready (required — OIDC needs HTTPS), deploy the container, configure nginx with HTTPS and set the APP_URL variable. Once installed, visit https://your-domain to complete the setup wizard.

In the Pocket ID admin interface, open OIDC Clients → New client. Enter the application name and the callback URL (e.g. https://git.your-domain.com/user/oauth2/pocket-id/callback). Pocket ID generates a client ID and secret to copy into your application's OIDC configuration. Gitea, Nextcloud, Grafana and n8n support OIDC natively.

All Pocket ID data — users, OIDC clients, passkeys and sessions — is stored in a SQLite file inside the Docker volume `pocket_id_data`. Back up the `/app/data` directory from the container: `docker cp pocket-id:/app/data /path/to/backup`. Schedule this command as a daily cron job for automated backups.

The OpenID Connect (OIDC) protocol requires the issuer to be a valid HTTPS URL — it cannot work over plain HTTP or with an IP address. APP_URL is set at first installation because it anchors the OIDC issuer identifier: all client applications verify that tokens originate from this exact URL. If you don't have a domain yet, you can use the free ServOrbit sub-domain provided with every VPS.

Partially. Penpot is a vector UI design tool: it handles flyers, posters and simple layouts better than Publisher, but it is not a DTP tool. It lacks multi-column text flow templates, bleed management, and PDF/X export for offset printing. For complex professional print needs, Scribus is a more suitable open source alternative. For internal communications, digital flyers or web newsletters, Penpot covers most use cases.

In your ServOrbit client area, go to the Marketplace, select Vane in the Artificial Intelligence category and click Install. The provisioning script deploys the Docker container, mounts the data volume at /home/vane/data and configures the nginx reverse proxy. The application is ready in a few minutes. Access it via an SSH tunnel (ssh -L 3000:127.0.0.1:3000 root@<ip>) or directly from your browser if you have configured a domain.

Vane is LLM-agnostic: connect Ollama (local models running on the same VPS or another server), OpenAI, Google Gemini, Groq or Anthropic. Without any provider configured, Vane runs in search-only mode (SearXNG results, no AI synthesis). For LLM answers without sending data to a third-party service, install Ollama on the same VPS and point Vane to http://localhost:11434 in Settings → Model Providers.

No. Vane does not require a domain name. Access the application via an SSH tunnel from your local machine: ssh -L 3000:127.0.0.1:3000 root@<your-vps-ip> then http://localhost:3000 in your browser. If you want direct browser access without a tunnel, configure a subdomain or custom domain through ServOrbit.

All Vane data — conversation history, settings and LLM provider configuration — is stored in the Docker volume vane-data, accessible at /home/vane/data inside the container. To back up, run on your VPS: docker run --rm -v vane_vane-data:/data -v /backup:/backup alpine tar czf /backup/vane-$(date +%Y%m%d).tar.gz -C /data . To restore, create the volume first, then extract the archive into it before restarting Vane.

The calculation starts from three cost items: current SaaS subscriptions (monthly cost × number of users × number of tools), the cost of the VPS that will host the replacement tools, at the public price, and the estimated migration time. For each client, the net saving over 12 months is the difference between the replaced annual subscription and the annual cost of those VPS, minus the time you will spend maintaining them. Our sales team can help you build this calculation via the Contact → Quote form.

From your ServOrbit client area, go to the Marketplace, select TREK in the Collaboration category and click Install. The provisioning script deploys the Docker container, mounts data volumes at /app/data and /app/uploads and configures the nginx reverse proxy. TREK is ready in a few minutes. The admin account is created automatically on first boot — credentials are available in your client area under Installed apps → TREK → Credentials.

No. TREK does not require a domain name. The application is accessible via SSH tunnel: ssh -L 3000:127.0.0.1:3000 root@<vps-ip> then http://localhost:3000. For permanent access from any device or to enable OIDC and email notifications, configure a subdomain or custom domain via ServOrbit and add APP_URL to TREK's environment variables.

All TREK data is stored in two Docker volumes: trek-data (SQLite database and settings) and trek-uploads (file attachments). To back up, run on your VPS: docker run --rm -v trek_trek-data:/data -v /backup:/backup alpine tar czf /backup/trek-data-$(date +%Y%m%d).tar.gz -C /data . Repeat with trek-uploads for attachments. To restore, create the volumes first, extract the archives into them, then restart TREK.

Yes. TREK supports single sign-on via OIDC. To enable it, add to TREK's environment variables: OIDC_ISSUER (your provider URL), OIDC_CLIENT_ID and OIDC_CLIENT_SECRET. TREK is compatible with Authentik, Pocket ID, Keycloak and any standard OIDC provider. You can also set OIDC_ONLY=true to enforce SSO as the only login method. APP_URL must be configured for the OIDC callback to work correctly.

In your client area, open the Marketplace, select Termix, choose the access address (a sub-domain of one of your domains or the VPS's free sub-domain) and click Install. The script deploys the Docker container and configures nginx over HTTPS, including WebSockets for the SSH terminal. Plan for at least 1 GB of RAM.

Yes, Termix opens over HTTPS on a domain — but you do not have to buy one. Every ServOrbit VPS comes with a free sub-domain (termix.{dns_slug}.servorbit-dns.com) with an HTTPS certificate, which you can pick at install time. You can also use a sub-domain of one of your own domains.

Open Termix's HTTPS address as soon as the installation finishes: the sign-up form appears, and the first account created becomes the administrator. Create it right away, then turn off public registration in the admin settings and enable two-factor authentication (TOTP) or a passkey.

All of Termix's data — SQLite database, encryption keys generated on first start, plugins — lives in the Docker volume mounted on /app/data. Back up that volume (for example with a scheduled tar archive or VPS snapshots): without the keys it holds, saved SSH credentials can no longer be decrypted.

In your client area, open the Marketplace, select Databasus and click Install. The script deploys the container, which initialises its internal database on first start. Plan for at least 1 GB of RAM, plus disk space for backups if you keep them on the VPS.

Databasus does not require a domain. Its interface is published on the VPS loopback: open an SSH tunnel with `ssh -L 4005:127.0.0.1:4005 root@<vps-ip>` (adjust the port to the one shown in the client area), then open http://localhost:4005. For permanent HTTPS access, attach a domain or the VPS's free sub-domain.

Yes. The recipe declares the host.docker.internal host, which points to the VPS from inside the container: use it as the database host. The PostgreSQL or MySQL server must then listen on the Docker network interface and allow that connection; ideally create a read-only user dedicated to backups.

Yes, at least one copy. A backup stored on the VPS disk protects against human error, not against losing the machine. Add an external destination — S3, Cloudflare R2, Google Drive, SFTP — and enable AES-256-GCM encryption so the files stay unreadable on that storage.

From your client area, open the Marketplace, select OpenProject, choose the access address (a sub-domain of one of your domains or the VPS's free sub-domain) and click Install. The script deploys the official Docker image and configures nginx over HTTPS. The first start takes three to five minutes; plan for 4 GB of RAM and 2 vCPU.

Yes, OpenProject opens over HTTPS on a domain and rejects requests addressed to any other name — but you don't have to buy one. Every ServOrbit VPS comes with a free sub-domain (openproject.{dns_slug}.servorbit-dns.com) with an HTTPS certificate, which you can pick at install time. You can also use a sub-domain of one of your domains.

The administrator account is created at install time: username admin, with a generated password shown in your client area next to the application address. No change is forced at first login: change it yourself from My account, then enable two-factor authentication.

After installation OpenProject has no outgoing mail server configured, so invitations, reminders and notifications are not sent. Enter an SMTP server under Administration → Emails and notifications (host, port, credentials), then send a test email from the same page.

The PostgreSQL database and attachments are in two Docker volumes, mounted on /var/openproject/pgdata and /var/openproject/assets. Back up both together with the container stopped (or with VPS snapshots), or use the built-in backup under Administration → Backup.

In your client area, open the Marketplace, select Healthchecks, choose the address and click Install. The script deploys the container, creates the administrator account and publishes the application over HTTPS. An Ubuntu 24.04 VPS with 1 GB of RAM is enough.

Yes, Healthchecks builds its ping URLs and alert links on its address. No need to buy one: every ServOrbit VPS comes with a free subdomain (healthchecks.{dns_slug}.servorbit-dns.com) with HTTPS. You can also use a subdomain of one of your domains.

Open the application's address and log in with [email protected] and the generated password shown in your client area. Public sign-up is closed: change the email address and password from the account settings, then invite your team.

Sending email requires an SMTP server. Add EMAIL_HOST, EMAIL_PORT, EMAIL_HOST_USER, EMAIL_HOST_PASSWORD and DEFAULT_FROM_EMAIL to the application's .env file, then restart the container. Meanwhile, webhook, Slack, Mattermost, ntfy or Gotify channels work without any server-side configuration.

In your client area, open the Marketplace, select Hasura, choose the address and click Install. The script deploys PostgreSQL and the Hasura engine, generates the admin secret, connects the database and publishes the API over HTTPS. An Ubuntu 24.04 VPS with 1 GB of RAM is enough to get started.

Yes, Hasura's API is called by your frontends and mobile apps: it must answer over HTTPS on a stable name. No need to buy one: every ServOrbit VPS comes with a free subdomain (hasura.{dns_slug}.servorbit-dns.com) with HTTPS. You can also use a subdomain of one of your domains.

Open https://your-domain/console and enter the admin secret shown in your client area. There is no username: this secret grants full rights over the API and the database. Never put it in frontend code; your users authenticate with a JWT.

Add HASURA_GRAPHQL_JWT_SECRET to the application's .env file (/opt/hasura), with your provider's public key URL (jwk_url): Logto, Authentik, Zitadel or Auth0. Restart with docker compose up -d, then define each role's permissions in the console's Permissions tab.

In your client area, open the Marketplace, select Jenkins, choose the address and click Install. The script deploys Jenkins LTS in Docker, with a dedicated data volume, and publishes it over HTTPS behind nginx. An Ubuntu 24.04 VPS with 2 GB of RAM is enough to get started.

Yes, Jenkins is shared by the team and receives the webhooks of your Git repositories: it must answer over HTTPS on a stable name. No need to buy one: every ServOrbit VPS comes with a free subdomain (jenkins.{dns_slug}.servorbit-dns.com) with HTTPS. You can also use a subdomain of one of your domains.

Open the HTTPS address of Jenkins: the wizard asks for the initial administrator password. It is shown in your client area, on the page of the installed application. Then install the suggested plugins and create your own administrator account; the initial password is no longer used after this step.

Not directly on the Jenkins server installed by the Marketplace: for security, the VPS's Docker socket is not mounted into it, as it would give any build root access to the server. Connect a build agent over SSH, for example a second VPS with Docker, and target it in your Jenkinsfile with a label.

In your client area, open the Marketplace, select Keycloak, choose the address and click Install. The script deploys Keycloak and its PostgreSQL database in Docker, with a dedicated data volume, and publishes it over HTTPS behind nginx. An Ubuntu 24.04 VPS with 2 GB of RAM is enough to get started.

Yes. Keycloak signs its tokens and builds its OIDC and SAML redirects from its public HTTPS address, so it must answer on a stable name. No need to buy one: every ServOrbit VPS comes with a free subdomain (keycloak.{dns_slug}.servorbit-dns.com) with HTTPS. You can also use a subdomain of one of your domains.

Open https://your-domain/admin and sign in with the username admin and the password shown in your client area, on the application's page. This master-realm account is temporary: create your own administrator with the admin role, then disable the original account.

Create a realm dedicated to your applications, then add an OpenID Connect client to it: declare your application's redirect URLs and copy its secret. In the application, enter the discovery address https://your-domain/realms/<your-realm>/.well-known/openid-configuration; most frameworks configure the rest from it.

In your client area, open the Marketplace, select VictoriaMetrics, choose the address and click Install. The script deploys the official container, generates the admin user's password, enables authentication and publishes the interface over HTTPS. An Ubuntu 24.04 VPS with 1 GB of RAM is enough to get started.

Yes: your servers send their metrics to it and Grafana queries it, so it must answer over HTTPS on a stable name. No need to buy one: every ServOrbit VPS comes with a free subdomain (victoriametrics.{dns_slug}.servorbit-dns.com) with an HTTPS certificate. You can also use a subdomain of one of your domains.

Open https://your-domain/vmui and enter the admin user and the password shown in your client area. The same credentials protect the query API and ingestion: Prometheus, your agents and Grafana use them as basic authentication.

Add a remote_write block to prometheus.yml with the URL https://your-domain/api/v1/write and basic_auth (the admin user and the password), then reload Prometheus. It keeps scraping and duplicates every sample to VictoriaMetrics. Grafana Alloy, vmagent and Telegraf accept the same address.

In your client area, open the Marketplace, select Kener, choose the address and click Install. The script deploys Kener and its Redis cache, generates the session secret key and publishes the status page over HTTPS. An Ubuntu 24.04 VPS with 1 GB of RAM is enough.

Yes, but you do not have to buy one. Kener rejects requests whose origin differs from its HTTPS address, so it needs a stable name. Every ServOrbit VPS comes with a free subdomain (kener.{dns_slug}.servorbit-dns.com) with an HTTPS certificate; you can also use a subdomain of one of your domains, for example status.your-domain.com.

Open https://your-domain/account/signin right after the installation and fill in the « Create Admin Account » form. The first account created becomes the administrator and the form then disappears: create it straight away. No password is generated in advance.

Enter an SMTP server (SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASSWORD, SMTP_SENDER) or a Resend key in the application's docker-compose.yml file, restart with docker compose up -d, then enable subscriptions in Kener's admin area. Your visitors then sign up from the status page.

In your client area, open the Marketplace, select marimo and click Install. The script deploys the official container with pandas, polars, numpy and altair, generates the editor password and creates the volume that keeps your notebooks. An Ubuntu 24.04 VPS with 2 GB of RAM is recommended.

The editor password is generated at install time and shown in your client area, on the application page. marimo asks for it on its login page; the session then stays open in your browser. On the VPS it is also in the stack's .env file, under the ADMIN_PASSWORD key.

Yes. marimo does not require a domain: without one, open an SSH tunnel (ssh -L 2718:127.0.0.1:<port> root@<vps-ip>) then http://localhost:2718, using the port shown in your client area. For direct HTTPS access, attach a subdomain of one of your domains or the VPS's free subdomain.

Notebooks are plain .py files stored in the marimo-data Docker volume, mounted on /app. The safest option is to version that folder in a Git repository; you can also archive the volume, and VPS backups cover it like the rest of the disk.

In your client area, open the Marketplace, select Kutt, choose the address of your short links and click Install. The script deploys the official container, generates the session secret key, creates the SQLite database volume and configures nginx over HTTPS. An Ubuntu 24.04 VPS with 512 MB of RAM is enough.

Yes, but you do not have to buy one. Kutt builds every short link from its domain: without a public address, links would point to a local machine. Every ServOrbit VPS comes with a free subdomain (kutt.{dns_slug}.servorbit-dns.com) with an HTTPS certificate; for truly short links, use a brief subdomain of one of your domains instead, for example go.your-domain.com.

Open your address over HTTPS right after the installation: Kutt redirects you to the form that creates the administrator account. Enter your email and a strong password; the first account created becomes the administrator, which is why you should create it straight away. No password is generated in advance, and public sign-up stays closed.

Generate an API key in your Kutt account settings, then send a POST to /api/v2/links with the X-API-KEY header and a JSON body containing target, the long address. The customurl, password, description and expire_in fields are optional. The response contains the link field, the short link; each team member has their own key.

In your client area, open the Marketplace, select Certimate, choose the console address and click Install. The script deploys the official container, generates the administrator password and applies it before the first start, creates the data volume and configures nginx over HTTPS. An Ubuntu 24.04 VPS with 512 MB of RAM is enough.

Yes: Certimate is a web administration console, published on a domain over HTTPS behind nginx. You do not need to buy one: every ServOrbit VPS comes with a free subdomain (certimate.{dns_slug}.servorbit-dns.com) with an HTTPS certificate. You can also choose a subdomain of one of your domains, for example certs.your-domain.com.

Open the console address: the username is [email protected] and the password is the one generated during installation, shown in your client area on the application's page. The factory password published by the project (1234567890) is never active on a ServOrbit installation. Change the email and password at your first login.

Yes. A Certimate workflow obtains the certificate (for example a wildcard through a DNS-01 challenge at Cloudflare or OVHcloud), then copies it over SSH to your servers and runs the reload command you choose, such as nginx -t && systemctl reload nginx. Use a dedicated SSH key and an account limited to the certificate directories. Other targets exist: cPanel, Nginx Proxy Manager, Kubernetes or webhook.

In your client area, open the Marketplace, select GreptimeDB, choose the address and click Install. The script deploys the official container, generates the admin user's password, enables authentication on the whole HTTP API and publishes the dashboard over HTTPS. An Ubuntu 24.04 VPS with 2 GB of RAM is enough to get started.

Yes. Your servers send their metrics, logs and traces to it, and Grafana queries it: GreptimeDB must answer over HTTPS on a stable name. No need to buy one: every ServOrbit VPS comes with a free subdomain (greptimedb.{dns_slug}.servorbit-dns.com) with an HTTPS certificate. You can also use a subdomain of one of your domains.

Open https://your-domain/dashboard/ and enter the admin user and the password shown in your client area in the dashboard's connection settings. The same credentials protect the SQL API, the Prometheus API and ingestion: Grafana and your agents use them as basic authentication.

In the OpenTelemetry Collector, declare an OTLP/HTTP exporter pointing to https://your-domain/v1/otlp with an Authorization header using basic authentication. Traces also require the X-Greptime-Pipeline-Name: greptime_trace_v1 header: put them on a second exporter, because that header gets logs rejected. They land in the opentelemetry_logs and opentelemetry_traces tables.

In your client area, open 1-click apps, select MLflow, choose the address and click Install. The script deploys the official container, generates the admin account's password, enables authentication on the interface and the API and publishes the server over HTTPS. An Ubuntu 24.04 VPS with 2 GB of RAM is enough to get started.

Yes: your scripts and your team connect to the server, and MLflow only accepts declared host names. No need to buy one: every ServOrbit VPS comes with a free subdomain (mlflow.{dns_slug}.servorbit-dns.com) with an HTTPS certificate. You can also use a subdomain of one of your domains.

Open your server's address over HTTPS: the browser asks for credentials. Enter admin and the password shown in your client area. You can change it later through the users/update-password API; the new password is kept across restarts.

Install the client with pip install mlflow, then set MLFLOW_TRACKING_URI to your server's HTTPS address, along with MLFLOW_TRACKING_USERNAME and MLFLOW_TRACKING_PASSWORD. Every mlflow.start_run() in your notebooks and scripts then records its parameters, metrics and files on your VPS.