Orbiter — Features Guide

Orbiter Shield — Kernel-Level File Protection

Shield protects CMS core files, plugins, and themes by mounting the document root as read-only (:ro) at the Docker/kernel level. This is not a chmod — even root inside the container cannot write to protected directories.

Built-in profiles

How to enable Shield

1. Open the domain's action panel
2. Click the Shield section
3. Select a profile (auto-detected based on CMS)
4. Click Enable — the container is recreated with read-only mounts

Important notes

• Enabling Shield recreates the container (brief downtime of a few seconds)
• If a plugin tries to write to a protected directory, it will get a Permission Denied error
• For WordPress: plugins that auto-update will fail — use the WordPress admin updater instead
• For Laravel: auto-detect distinguishes between Plesk-style layout (app inside docroot) and standard layout (app at parent of public/)
• The nginx exec-block additionally blocks execution of .php, .pl, .sh, .py files in writable zones as defense-in-depth

Disabling Shield

Disable from the Shield section in the actions panel. The container is recreated in read-write mode.

Orbiter Fortress — Anti-Exfiltration & WAF

Fortress is a multi-layer hardening profile applied per domain. Where Shield protects the filesystem (read-only mounts), Fortress focuses on runtime protection: blocking dangerous PHP functions, restricting filesystem reach, filtering malicious HTTP requests, limiting outbound traffic, and scanning uploads.

The layers

• WAF (nginx) — request filtering: SQLi/LFI/XSS patterns, bad user-agents, scanner signatures, xmlrpc, .env/.git access, blocked. Returns 403.
• PHP hardening — disable_functions (exec, eval, system, …) injected into the pool, plus open_basedir confinement to the domain's paths.
• Egress control — iptables rules limiting the container's outbound connections (permissive / standard / strict).
• Upload scanner — watches writable upload dirs, detects real MIME types, re-encodes images, quarantines suspicious files.
• WP cleanup — removes residual Orbiter mu-plugins on sites previously protected.

How to enable Fortress

1. Open the domain's action panel → Fortress
2. Pick a use-case profile (or Advanced for full control)
3. Save — layers are applied without recreating the container in most cases

Advanced: manual lists and paths

The Advanced section (labelled "Advanced — manual lists & paths" in the UI) gives you direct, fine-grained control over two things that the profiles otherwise manage for you:

1. Blocked PHP functions (disable_functions)

A grid of checkboxes listing every PHP function Fortress can disable for this domain (exec, shell_exec, system, passthru, eval, proc_open, popen, parse_str, …).

• A checked function is blocked — PHP will throw a fatal error if the application tries to call it.
• Uncheck a function to allow it again — do this when a legitimate plugin or framework needs it (e.g. a backup plugin that shells out, or an image library using proc_open).
• Use the text field to add a custom function not in the default list (comma-separated). This appends to the domain's disable_functions directive.

⚠️ Blocking exec/system/proc_open is the single most effective mitigation against PHP web-shells — keep them blocked unless a specific feature breaks. When something breaks with a "call to undefined/disabled function" error, this is the first place to look.

2. open_basedir extra paths

By default Fortress confines PHP file access to the domain's own document root and its standard sub-paths. If your application legitimately needs to read or write outside that tree (a shared library directory, an NFS mount, a sibling project), add the absolute path here — one per line.

• Each path must stay under /var/www/vhosts/ (paths outside this tree are rejected for safety).
• Adding a path widens the sandbox — only add what's strictly necessary. Every extra path is a potential exfiltration route if the site is compromised.
• Leave empty to keep the strict default confinement.

When to use Advanced vs a profile

• Use a profile if your stack matches one of the use-cases — it's curated and maintained.
• Use Advanced when no profile fits, when a profile is too strict for a specific plugin, or when you need to widen open_basedir for a non-standard layout. Changes are per-domain and persist across container recreations.

Disabling Fortress

Disable from the Fortress section in the actions panel — all layers (WAF, PHP hardening, egress, upload scanner) are removed and the original nginx/PHP configuration is restored.

Upload Scanner — Real-Time Monitoring

The Upload Scanner is the Fortress layer that inspects file contents the moment they land on disk. Where the WAF blocks malicious requests and Shield locks the filesystem read-only, the Upload Scanner watches the writable upload directories (which by definition can't be read-only) and catches malware that slips through as an "image" or "document".

How it works

A lightweight Python watcher runs as a systemd service, one per domain. It uses inotify to react in real time: every file written or moved into a watched directory is scanned within milliseconds — no cron, no polling, no delay. Suspicious files are moved to a quarantine folder and chmod 0400 (read-only, owner only) so they can never be served or executed.

What gets watched

The scanner auto-targets the writable upload paths of the detected CMS:

You can add extra directories to watch from the Fortress → Upload Scanner panel (each must stay under /var/www/vhosts/).

The 7 checks

Each check can be toggled individually per domain without stopping the whole watcher:

1. MIME type (scan_mime) — reads the real type via libmagic (not the filename extension). Rejects anything outside the allowed list (images, PDF, common documents).
2. PHP payload (scan_php) — raw-byte regex scan for PHP code / dangerous function calls anywhere in the first 1 MB. Catches <?php web-shells disguised as .jpg.
3. ZIP inspection (scan_zip) — inspects archive entries, guards against ZipSlip (path traversal) and zip bombs.
4. SVG sanitization (scan_svg) — parses the XML and refuses <script>, javascript: URLs, and on* event handlers (SVG is a classic stored-XSS vector).
5. PDF inspection (scan_pdf) — flags /JavaScript, /Launch, and /EmbeddedFile actions.
6. Entropy check (scan_entropy) — Shannon entropy > 7.5 on text/plain / application/json files (detects packed/encrypted payloads hiding in "text").
7. Image regeneration (scan_regen) — re-encodes JPEG/PNG/GIF/WebP from pure pixel data via Pillow. This strips every metadata chunk — EXIF, IPTC, XMP, ICC, comments — so anything embedded in metadata (a common exfil/payload trick) is destroyed. The image looks identical; the hidden bytes are gone.

Quarantine

Suspicious files are moved to quarantine/<file>.<timestamp>.<reason> and made read-only. From the Quarantine viewer (Fortress panel) you can review flagged files, see why each was caught, restore a false positive, or bulk-empty the quarantine.

A configurable TTL (7 / 14 / 30 / 60 / 90 days, or never) auto-purges old quarantined files via a daily cron, so the folder never grows unbounded.

Enabling & configuring

1. Enable Fortress (the scanner is one of its layers — on by default).
2. Open Fortress → Upload Scanner to:
   • toggle the watcher on/off,
   • add extra watched directories,
   • enable/disable any of the 7 checks individually,
   • set the quarantine TTL,
   • run an injection test (drops a benign test payload to confirm the watcher catches it).

Notes

• The watcher requires python3-magic (libmagic) and python3-pil (Pillow) on the host — installed automatically by Orbiter.
• Recreating or migrating a domain simply rewrites the watcher's directory map and restarts the service — no reconfiguration needed.
• Clean, non-image files are left untouched; only flagged files are quarantined.

Web Application Firewall (WAF)

The WAF is the Fortress layer that filters incoming HTTP requests at the nginx level — before they ever reach PHP. Each rule inspects the URL, query string, or headers and returns 403 Forbidden on a match. It's the first line of defense against the most common automated attacks.

What each rule does

Consequences to keep in mind

• It can block legitimate traffic. Every rule is a trade-off between security and compatibility. If a feature of your site stops working after enabling Fortress (a form returns 403, an integration fails), the WAF is the first place to look — open the WAF tab and uncheck the offending rule.
• xmlrpc is the most common one to disable on WordPress sites that use the mobile app or Jetpack.
• The WAF only sees what passes through nginx. Requests served from the cache or handled by a CDN in front of the server are not inspected by it.

Security headers

When the WAF is active, Fortress also adds modern security response headers: X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, Referrer-Policy, Permissions-Policy, and a Content-Security-Policy that restricts which external domains can load scripts/styles/fonts. See the Advanced — manual lists & paths section if you need to allow an external CDN.

Tuning

All rules are toggled per domain in Fortress → WAF, or guided by the configuration wizard when you first enable Fortress. Changes apply immediately (nginx reload), with an automatic rollback if the generated config fails nginx -t.

PHP Hardening — Standard vs Strict

PHP hardening injects a disable_functions directive into the domain's PHP-FPM pool, neutralizing the functions most abused by web-shells and exfiltration scripts. It also confines file access with open_basedir. Orbiter offers two levels.

Standard (recommended)

Blocks the system-execution and low-level functions — the ones a PHP web-shell needs to do real damage:

exec, system, passthru, shell_exec, popen, proc_open, pcntl_exec, pcntl_fork, proc_*, fsockopen, pfsockopen, raw socket_* / stream_socket_*, assert, dl, phpinfo, link, symlink, putenv.

This is compatible with the vast majority of CMS and plugins, because normal PHP apps don't shell out to the system. It's the single most effective anti-RCE mitigation.

Strict

Everything in Standard plus the network & mail functions:

file_get_contents, fopen, curl_init, curl_exec, curl_multi_*, dns_get_record, gethostbyname, gethostbyaddr, getmxrr, checkdnsrr, mail.

This blocks a compromised site from phoning home (exfiltrating data or pulling a second-stage payload) — but it's intrusive.

⚠️ Strict breaks a lot. Any plugin that calls an external API, fetches a remote URL, sends email via PHP mail(), or resolves DNS will stop working. Reserve Strict for isolated sites (internal APIs, static/marketing sites with no outbound needs). For a normal WordPress/WooCommerce site, use Standard.

Consequences & how to recover

If a feature breaks after enabling hardening you'll typically see a "Call to undefined function" or "… has been disabled for security reasons" error in the PHP log. To fix it:

1. Open Fortress → PHP → Advanced — manual lists & paths.
2. Uncheck the specific function the plugin needs (e.g. re-allow curl_exec for a payment gateway).
3. Save — the change is per-domain and persists across container recreations.

You can also add custom functions to block, or widen open_basedir for non-standard layouts. See Advanced — manual lists & paths.

Note on egress

Strict's network-function block is a PHP-level control. For a kernel-level outbound restriction (independent of PHP), use the Egress layer (permissive / standard / strict iptables rules) instead — it can't be bypassed by an alternative PHP function.

Egress Control — Outbound Network

Egress control restricts what the container can connect to on the way out, using kernel-level iptables rules on the container's IP. Unlike PHP disable_functions (which a clever payload might route around), egress rules apply to every process in the container — PHP, a shell, a compiled binary — so a compromised site cannot phone home or pivot to your internal network.

The three modes

In Strict mode you provide an allow-list of IPv4 addresses (or CIDR ranges) in the Fortress panel; any other destination is rejected.

Consequences to keep in mind

• Strict will break anything you forget to allow — plugin update servers, SMTP relays, third-party APIs, license checks. Start from Standard and only move to Strict once you know every endpoint your site contacts.
• Egress is kernel-level and stronger than PHP Strict's network block, but the two are complementary: PHP hardening stops the function from existing, egress stops the packet regardless of how it's sent.
• Blocked connections are rejected (not silently dropped), so PHP gets a clear "connection refused" error you can trace.

Upload Scanner

The same wizard step toggles the Upload Scanner — the real-time watcher that inspects uploaded file contents. It's covered in detail in its own section: Upload Scanner — Real-Time Monitoring.

Tuning

Set the egress mode (and Strict allow-list) in Fortress → Egress, or via the configuration wizard. Rules are applied immediately and removed cleanly when Fortress is disabled.

Nginx Cache

Orbiter includes a built-in Nginx FastCGI/proxy cache that can speed up pages up to 10x for visitors.

Enabling cache

Go to the domain's Cache section in the actions panel and click "Enable cache". Choose a CMS profile for automatic exclusions (admin areas, cart, checkout, etc.).

Cache TTL options

1 minute (debug), 5 minutes, 15 minutes, 30 minutes, 1 hour, 6 hours, 24 hours.

Advanced options

• Bypass on query strings — Exclude URLs with ?parameter from cache
• Custom URLs to exclude — One URL per line, Nginx regex supported
• Custom cookies to bypass — If a specific cookie is present, skip cache
• Ignore Cache-Control — Cache even if PHP sends Cache-Control: no-cache
• Ignore Set-Cookie — Cache even if PHP sends a session cookie
• Separate mobile cache — Serve different cached content to mobile devices
• Purge token — Token for purging cache from an external script (e.g. after deployment)

Cache purge

Use the "Purge cache" button in the Cache panel, or call the cache purge endpoint with the configured token.

Resource Limits

Each container supports independent resource limits set from the sliders icon on the domain row.

PHP-FPM limits (separate from container limits):

• pm.max_children — Maximum concurrent PHP workers
• request_terminate_timeout — Time before a PHP script is killed
• ProxyTimeout (Apache mode only) — Time before Apache returns 504 to the client

Native Plesk Limits — Protect Orbiter from Non-Containerized Sites

Found at Sites → Native Plesk limits. These caps protect the host from sites that are still running natively under Plesk (not yet containerized). A native Plesk site that runs amok — buggy WordPress plugin, looping cron, attack — can saturate the server's CPU/RAM and disrupt Orbiter and every containerized site alongside it. The three levels below are a safety net for that case.

Sites inside an Orbiter container are not affected. They are already isolated with their own Docker limits (configured per container from the sliders icon — see Resource Limits above).

The three levels (systemd cgroup v2)

Orbiter writes a drop-in for each level. The kernel enforces the cap; processes are throttled as soon as they exceed it.

Each level has its own preset row — Conservative, Standard, Generous, Unlimited — plus editable CPU / RAM / Tasks fields. The Guided setup button at the top walks you through all three in one wizard with concrete scenarios.

Important: granularity is at the service level, not per-site

systemd cgroup assigns processes by the launcher, not by the Unix UID they run under. That has two consequences for PHP-FPM:

• The PHP-FPM cap is enforced — but it's a single ceiling shared by every site served by that PHP version. You can't set CPU 100% on siteA.com and CPU 200% on siteB.com via systemd. Both share the same plesk-php84-fpm.service cgroup.
• For per-site PHP-FPM tuning, use Plesk's native controls: Domains → site → PHP Settings — pm.max_children, pm.max_requests, request_terminate_timeout, php_admin_value[memory_limit]. These don't throttle CPU at the kernel level, but they cap concurrency and per-worker RAM.
• If you need true per-site CPU/RAM caps with kernel throttling, containerize the site. Each Orbiter container is its own cgroup with its own limits.

Per-user CLI overrides

The User CLI tab has a sub-tab Per-user overrides — a table of every Plesk system user (one per primary domain) with search, filter chips (All / With override / Inherits global) and pagination. The Configure button on a row opens a mini-modal with the same presets to set a user-specific cap that takes precedence over the global default. Useful when one client legitimately needs to run heavy WP-CLI jobs (e.g. wp media regenerate on 50,000 images).

Override is written to /etc/systemd/system/user-<UID>.slice.d/orbiter-override.conf. Removing it (button Remove override) deletes the drop-in and the user reverts to the global cap, applied live.

What a typical setup looks like

The wizard's Standard preset on a balanced server gives:

A buggy plugin causing a runaway loop is then capped at 2 cores and 4 GB of RAM, regardless of which native site it runs on — the server stays responsive for everything else, including the containerized sites.

What is not covered

These caps protect Orbiter and other sites from misbehaving native Plesk sites. They do not protect a native site from itself — a site running a 60-second SQL query will see that query terminated only if its own pool's request_terminate_timeout kicks in. For full isolation (CPU/RAM/IOPS strictly enforced per site, plus filesystem isolation, plus its own MariaDB if needed), containerize the site via Containerize on its row.

Server Capacity — Containers Still Creatable

The Capacity tab on the Dashboard estimates how many more containers your server can still host before running out of resources. It is a planning aid, not a hard limit — Orbiter never blocks creation based on this number.

How the estimate works. Orbiter looks at the server's free resources (RAM, CPU, disk, and kernel limits such as PIDs/process counts) and divides them by the typical footprint of a container. The result is the most constrained dimension — i.e. whichever resource runs out first sets the ceiling.

Why the number changes. The estimate is dynamic: starting a database container, raising a container's resource limits, or other sites getting busier will lower it. It refreshes automatically and can be refreshed manually from the tab.

Containers with an integrated MariaDB count more heavily than database-less containers, because each embedded MariaDB reserves memory and processes. If the capacity is lower than expected, MariaDB-enabled containers are usually the reason.

Best practice. Treat the figure as a safety margin. Leave headroom rather than provisioning right up to the estimate, so existing sites keep enough resources under load.

Write Optimization — Reduce Disk I/O

Write Optimization reduces how much the container writes to disk — which means less SSD wear, lower I/O wait under load, and far less noise for the Imunify real-time scanner (every disk write is a syscall Imunify may hook). Each level trades a bit of persistence for performance. The container must be recreated to apply a change (the tmpfs mounts can't be added to a running container).

The three levels

Disabled — full disk persistence (default) Logs and sessions are written to disk as usual. Highest write count, full crash safety. Nothing is lost on a hard reboot.

Safe — logs in RAM + opcache lock (recommended)

• Supervisor, PHP-FPM and nginx logs are mounted on tmpfs (RAM): /var/log/supervisor (20 MB), /var/log/php-fpm (100 MB), /var/log/nginx (50 MB).
• OPcache is locked with a 5-minute revalidation (opcache.revalidate_freq=300), so PHP stops stat()-ing every file on each request.
• Result: I/O writes reduced ×20–50.
• ✓ Benefit: big I/O reduction with minor trade-offs — safe for almost all sites, including WordPress / WooCommerce.
• ⚠ Trade-off: up to ~5 s of logs lost on a hard crash; code changes are invisible to OPcache until the 5-minute refresh (or a PHP-FPM reload).

Aggressive — sessions in RAM

• Everything in Safe plus PHP sessions on tmpfs: /var/lib/php/sessions (100 MB).
• Result: disk writes near zero.
• ✓ Benefit: best for blogs, showcase, demo, and read-only sites.
• ⚠ Trade-off: sessions are LOST on container restart — logged-in users are logged out, carts emptied. Do not use for e-commerce or member areas.

How to choose

• WordPress / WooCommerce / any site with logins or carts → Safe.
• Static / showcase / blog / demo / API with no PHP sessions → Aggressive is fine and gives the biggest gain.
• Compliance needs full on-disk logs → keep Disabled.

Applying

Set it from the domain's Performance → Write Opt menu. Changing the level recreates the container (~10 s downtime). Logs written to tmpfs are volatile by design — if you need to keep them, ship them off-box (the Logs panel / external syslog) before relying on Aggressive.

Git Deploy

Configure automatic deployment from a Git repository.

Setup

1. Open the domain's action panel → Git Deploy section
2. Enter the repository URL, branch, and deploy secret
3. Optionally add a post-deploy hook (shell command run after each deploy)
4. Use the "Deploy now" button for manual deploy, or use the webhook URL for CI/CD push triggers

Security note

The git-set route is restricted to admin users only. Domain users cannot configure git deploy.

Uptime Monitoring

Orbiter monitors each domain with 1-minute HTTP probes.

Setup

Enable uptime monitoring from the domain's action panel. Configure:

• The path to probe (default: /)
• Alert email for downtime notifications

History

The uptime history view shows downtime windows with timestamps. The monitoring cron runs every minute.

Email Alerts

Configure per-domain email alerts for container events.

Alert types

Anti-spam

The same alert type is not resent within 60 minutes (configurable cooldown).

Maintenance Mode

Put a domain in maintenance mode with a custom 503 message.

Features

• Custom maintenance message displayed to visitors
• Admin IP bypass — your IP can still access the site normally
• One-click enable/disable from the domain's action panel
• Overrides Plesk's default maintenance page

Per-Domain Quotas

Administrators can set resource quotas per Plesk client:

• Maximum number of containers
• Maximum total RAM across all containers
• Maximum number of databases

Quotas are enforced at container creation. If a quota is exceeded, the creation is blocked with a "Quota exceeded" error.

External Backup Sync

Backups can be automatically synced to external destinations after each scheduled backup.

Supported destinations

• Amazon S3 (and S3-compatible storage)
• SFTP
• FTPS

Setup

Go to Settings → Backups → Backup Destinations. Add a destination, configure credentials, and use "Test connection" to verify. Enable "Automatically sync to all external destinations" to sync after each automatic backup.

OPcache Dashboard

View per-container OPcache statistics: hit rate, memory used, cached scripts. One-click reset from the PHP panel.

Page Speed Test

Run a TTFB (Time To First Byte) test with phase breakdown via curl directly from the Orbiter interface. An optional external probe via SSH provides realistic network latency measurements.

Web Console

Full terminal access inside each container from the browser.

• Runs as the domain owner's user (proper file permissions)
• Supports standard bash commands: ls, cd, cat, grep, etc.
• PHP tools available: composer, artisan, wp-cli
• Direct MariaDB access via the mysql client
• Console access can be disabled by administrators per container

Action Log

Each domain keeps an audit trail of who did what and when:

• Container create, delete, recreate
• Shield enable/disable
• PHP version changes
• Notes added

View the action log from the domain's action panel → Notes section.

CLI Commands

Orbiter exposes 148+ CLI commands via plesk ext orbiter --<command>.

Common commands

# Container management
plesk ext orbiter --create-container <domain>
plesk ext orbiter --delete-container <domain>
plesk ext orbiter --recreate-container <domain>
plesk ext orbiter --start-container <domain>
plesk ext orbiter --stop-container <domain>
plesk ext orbiter --restart-container <domain>

# PHP
plesk ext orbiter --set-php-version <domain> --php-version 8.2
plesk ext orbiter --get-php-config <domain>
plesk ext orbiter --set-php-config <domain> --key memory_limit --value 512M

# Database
plesk ext orbiter --db-export <domain> --db-name mydb > dump.sql
plesk ext orbiter --db-import <domain> --db-name mydb --file dump.sql

# Shield
plesk ext orbiter --shield-enable <domain> --profile wordpress
plesk ext orbiter --shield-disable <domain>
plesk ext orbiter --shield-status <domain>

# Monitoring
plesk ext orbiter --system-health
plesk ext orbiter --version
plesk ext orbiter --os-info

Note on db-export

The SQL dump goes to stdout. Redirect to a file:

plesk ext orbiter --db-export <domain> --db-name mydb > dump.sql 2>/dev/null

Status messages go to stderr and will not contaminate the dump file.