Everything a hosting business runs on
One panel for the operator and the customer, built on isolation and tuned for speed. In closed beta, by invitation — what follows is what the panel does; ask for a walkthrough.
The short version
The differences that decide whether this panel suits you, one line each.
- Every account is isolated from every other. One customer’s code cannot see or read another customer’s site, files or mail, and limits keep one account from starving the rest.
- Your
.htaccessis read, not ignored. Every directive in it is listed back to you, saying what it asks for and what the platform does about it, and one switch per site has the web server apply its common rewrites, redirects and deny rules — so a migrated site stops silently losing its protections. - Eleven PHP versions, 5.6 to 8.4, chosen per account. An optional check parses the site’s code on the new version beforehand, a move past a failed check has to be confirmed, and if the new version’s container does not start, the account goes back to its old version by itself. Customers pick their own extensions from a vetted list, ionCube included.
- WordPress security is free on every tier. Vulnerability detection, virtual patching and security updates for plugins — because a site’s safety is not a business feature.
- A page cache you can leave on, because it can clear a single page when that page changes.
- HTTP/3 and Brotli out of the box, and WebP with one switch per site.
- Staging that costs what changes. A staging copy takes almost no disk until something on it changes: cloning a 64 MB site’s files used 8 KB when we measured it. On the paid tiers.
- Stopping an account does not take its mail down. A stopped account’s sites answer a “temporarily unavailable” page while its mailboxes keep receiving and sending. A compromised account can be suspended, so its pages answer 503 and its mailboxes stop sending, while its mail keeps arriving.
- An infected site does not get your server blocklisted. A package sets an hourly ceiling on recipients — 200 on new packages, none at 0 — a burst pauses the account’s site mail and scans it for malware, and outgoing mail is spam-scored.
- Mail clients configure themselves. A customer types their address and password and Thunderbird, Apple Mail or Outlook connects.
- Accounts move in, across and out. Backups from cPanel, Plesk, DirectAdmin and CWP import; a move between your servers carries the databases with their passwords; every account exports in the cPanel format.
- Backups are proven by restoring them, weekly, and — where the server can run the check — by asking the restored site for a page.
- Backups are cheap to send and cheap to keep. After the first night only what changed travels, and content many accounts share is stored once.
- A hacked server cannot delete its own backups. The backup server accepts new backups and never takes orders to remove them.
- Recovery is yours. Everything needed to rebuild a server is locked to a recovery key only you hold — with an offline key of ours as a safety net, so a lost key is a support call rather than a catastrophe.
- Your customers see their own history: what changed, whether their own people or the host changed it, and what was refused.
- Customers add their own colleagues, each with only the sections they are given.
- A licence lapse never stops the hosting. Websites, mail and databases keep running whatever the licence says.
Isolation
Every account runs on its own, with its own PHP, its own caches and its own limits: there is no route from one tenant’s code to another’s files, database or mail.
Limits are enforced, not advertised: CPU, memory, processes, disk, file count and bandwidth per plan, applied from outside the account where nothing inside it can opt out. Accounts have no network path to the server’s own services; their database and their outgoing mail reach them through sockets of their own.
The parts of the platform every tenant touches — the web server, each account’s PHP, each account’s mail delivery — are locked down as well, and the Server page shows that they are, or says when one is not. Every program an account’s PHP starts is recorded, so a site that suddenly starts running shell commands is visible.
Where a site’s code should never change, its files can be made read-only with the upload folders left writable, so a compromised plugin cannot write itself back in.
Performance
HTTP/3, Brotli beside gzip, and a full-page cache that can clear a single page — the reason a page cache here is safe to leave on instead of being a support liability.
A private object cache per account on the plans that include one, tuned PHP with JIT on PHP 8 and optional preloading for WordPress, WebP without a plugin — one switch per site — and preload hints so browsers start on stylesheets and fonts sooner. Behind a CDN whose address ranges you enter, the real visitor address still reaches every log, rate limit and block.
PHP capacity is sized per plan — always warm, or on demand for accounts that are mostly idle — and the panel shows how much of it a site is using.
Runtimes
Build only the stacks you want — at the first run, or later with one button:
- PHP 5.6, 7.0 to 7.4, and 8.0 to 8.4 — eleven versions, chosen per account. The ones past their end of life are labelled as such, and are there for the sites that arrive on them
- Node.js 22
- Python 3.11
- Ruby 3.1
- .NET 8
- Java 17 (OpenJDK)
PHP customers pick their own extensions from a vetted list, without raising a ticket. Application stacks install their dependencies — npm, pip or gem — from the panel.
Speed you can prove
Each domain opens with a plain answer to “is this site fast?” — a verdict from a week of response times, then every speed setting with its state for that site and a button where one is off.
Real-user timings per site when switched on, slow-request logs that name the script rather than the symptom, the account’s slow database queries, and a before-and-after comparison when a setting changes. “The site feels slow” ends with a measurement instead of a shrug.
Traffic
Traffic per site, counted from its own access log: visitors, top pages,
referrers, and crawlers by name, AI crawlers included — kept for 90 days, with
visitors counted by a hash of their address (pseudonymous, not anonymous). A sitemap check lists the
pages a site advertises that answered a crawler “not found”, and an
llms.txt can be written from the sitemap. The site’s access, error and slow
logs are followed and filtered from the panel.
WordPress
Security, on every tier. Every WordPress on the server is checked against a vulnerability feed that refreshes several times a day — core, plugins and themes — and each finding names the version that fixes it. A site’s own people choose what happens next: a notification, virtual patching that blocks the attack without touching the site’s code, or security updates for plugins even where automatic updates are off, with a restore point taken first.
The toolkit around it. One-click installs, sign-in to wp-admin from the panel, updates to core, plugins and themes with a restore point behind each, automatic updates by policy with a per-site override, an integrity scan, hardening switches, and plugin sets you define once and install anywhere. On the paid tiers, an update can be tried on a throwaway staging copy first.
For the operator, every WordPress on the server on one page, with the same actions in bulk.
Sites
Staging that costs what changes, with its own hostname, certificate and copy of the databases, so nothing done there reaches the live site. When the account is full, the staging copy stops growing; the live site is never refused because of it. On the paid tiers.
Deployment from your customers’ own git repositories — which never runs code from the repository while deploying. Also on the paid tiers.
WordPress installs in one click: the panel creates its database, writes its
configuration and finishes the install. Matomo, Joomla, Grav, PrestaShop and
Nextcloud are unpacked into the site’s folder, and you finish each in its own
web installer with a database you created first (Grav needs none). Until you
do, whoever opens the site first can complete that installer, so finish it
straight away. Per-site
controls cover what support tickets are usually about — redirects, error pages,
access rules, protected directories, hotlink protection, security headers and
HSTS — and a robots.txt setting that asks AI crawlers to stay away without
turning search engines away too.
When one thing breaks
Stopping an account does not take its mail down. A stopped account’s sites answer a “temporarily unavailable” page (503), static files and cached pages included, while its domain keeps receiving mail, its mail clients keep sending and FTP still reaches its files; Start brings it all back. A compromised account can be suspended, so its pages answer 503, its mailboxes stop sending and FTP logins are refused, while its mail keeps arriving — and Start does not lift a suspension.
A customer whose site has been hacked can put it in rescue mode themselves: the site’s code and its scheduled tasks stop and visitors get a maintenance page, while files, FTP, backups and mail carry on. Static files keep serving when an application falls over — and the uptime check deliberately looks past the cache, so a dead application is noticed rather than hidden behind it.
Clients configure themselves. A customer types their address and password into Thunderbird, Apple Mail or Outlook and it connects — no server names, no ports, no encryption dropdown, no support ticket. On most hosts that is the single largest category of support contact.
The rest is complete rather than token: mailboxes with quotas, forwarders and
catch-alls, autoresponders with a date window, distribution lists, spam
filtering and virus scanning, and webmail your customers open from the panel
without typing a password. Old mail is copied across from Gmail, Microsoft 365
or any IMAP server. A domain whose mail stays at Google or Microsoft can keep
it there while its site is here, and a domain can give its mail clients its
own mail. hostname. Customers see the queue for their own mail; you see the
server’s. Your own team’s addresses live in staff mail, with no website
attached.
The records that decide whether mail is trusted are generated, published and watched rather than left as a checklist somebody forgot — a DANE record included, kept in step with each certificate renewal — and blocklists, the reverse record, bounces and DMARC reports sit on one page, so you find out your address is listed before a customer telephones to tell you.
When a site sends spam
An infected contact form is how most servers end up on a blocklist, so outgoing mail is counted rather than trusted. A package sets an hourly ceiling on recipients, 0 for none — 200 on new packages and on the two a fresh install ships — and each site may use half of its account’s. A site’s own mail goes out through the panel, signed with the domain’s key; when a site uses up its share, or the account’s site mail passes the ceiling or your burst alert, it is paused and the account scanned for malware, and its owner and you are told. The owner turns it back on from the Mail page, after checking the site: the panel does not wait for the scan to come back clean first. Each message is recorded with the script that sent it, so the infected file is named rather than hunted for.
Outgoing mail is spam-scored, and refused past a threshold of its own. Forwarders, lists and autoresponders cannot turn one message into thousands: a forwarder reaches at most 20 addresses, and lists cannot be nested through one. A mailbox sends only as a domain its account has shown it controls — its mail delivered here, its DKIM key published, or its certificate issued here. Every dedicated sending address is checked against blocklists, and a listing has the account scanned. Connections from an account’s sites to outside providers’ submission ports are counted too: past the ceiling, the account and you are told and the account is scanned.
DNS and certificates
DNS through ZoneForge, our hosted nameservers, is an option offered today rather than a guarantee. With it, the panel writes every account’s zone, with its mail and discovery records, checked before it is published; DNSSEC is one switch per zone, with the record for the registrar shown; the record editor is one your customers can be trusted with; and expiring domain registrations are a warning a month ahead rather than an outage.
Or keep your own authoritative DNS. The panel speaks the standard for it: certificates, wildcards included, are proved through RFC 2136 dynamic updates signed with a TSIG key, which BIND, PowerDNS, Knot and Windows DNS all accept, and the records each account needs are listed for you to publish.
Certificates issue with one click and renew on their own, and cover everything the server answers on. Bring your own where a customer insists.
Data
MariaDB for every account, and PostgreSQL on the paid tiers where the operator installs it. A database browser good enough that customers stop asking for phpMyAdmin — tables, indexes, row editing and a read-only query box on MariaDB, table browsing on PostgreSQL — plus database users with their own grants, import, export and read-only remote access for the reporting tool that needs it.
Files and access
A file manager that edits, uploads, extracts archives and downloads whole folders as a zip. FTP only over TLS, for the login and every file transfer, so neither a password nor a file crosses the network in the clear. SSH and SFTP by key, where the plan allows it. Cron jobs with a run-now button, a run history and each task’s output kept.
File history for customers. Hourly and daily restore points can be browsed from the file manager, a single file restored, and the changes between two points listed — so “I overwrote it this morning” stops being a support ticket.
Backups and recovery
Proven weekly, not promised. The panel restores the account whose backup has gone longest unproven into a throwaway copy and, where the server can run the check, asks the restored site for a page — without going anywhere near the live one. Most hosts cannot say when a restore was last tested.
On the server: hourly and daily restore points, and nightly database backups. Off the server, every night, to a backup server you control, which accepts new backups and never takes orders to delete them — so a compromised server cannot destroy what would have recovered it. Retention runs on the backup server itself: the last seven nights, everything within a month, and a monthly copy for six months. Encryption is chosen once, at the first run. A backup the night could not make is reported to an administrator as a notification. The notification is the signal: the nightly job itself still ends as succeeded, so a green job is not proof that every account reached the backup server.
Efficient to send and to keep. After the first night each backup sends only what changed, so the nightly transfer stays small. Content is stored once across nights and across every account on the server — the WordPress files many sites share are kept a single time — and it is compressed, with encryption costing none of that saving. Every night is still a complete backup that restores on its own: removing an old one never damages a newer one. Database backups are the exception — each is a whole, compressed copy.
Customers restore on their own: a file, one database — with a copy of the current one kept first — or the whole account. While a whole-account restore runs, the panel refuses anything else that would write into that account, and a PostgreSQL database is restored in a single transaction, so a restore that fails part way leaves it as it was.
Behind that sits the part that matters when a machine is gone for good: everything needed to rebuild a server is locked to a recovery key only you hold, with an offline key of ours as a safety net. The panel checks weekly that everything a rebuild needs is safely offsite, and tells you when it is not. A complete account export is always available, on every tier.
Moving accounts
Between your servers, an account moves while it keeps serving: its files are copied while the site runs, and it stops only for the last changes, its databases and the switch. MariaDB and PostgreSQL databases travel with their users’ passwords, so the site’s configuration works unchanged; a password that cannot be carried is replaced, and the new one written down for you. The old server waits until the new one reports the account imported and its container built, every database matching what was sent, before it points DNS there. Mail that arrives meanwhile is held and handed over once the new server takes it. A site deployed from git keeps its repository and deploy key, and a push to the old server is told where the site went.
Until you commit, a stopped copy stays behind and rolling back is one button. A move left unfinished, on either server, is noted, with a link to the page of the manual that says what to do about it.
From other panels, a full-account backup from cPanel, Plesk, DirectAdmin or CWP imports with its files, databases, DNS zones, certificates and cron jobs. Out again, every account exports as one archive in the cPanel format — files, databases, mail and cron.
Security
Isolation first, then the controls around it: sessions you can see and revoke, scoped API keys, a password confirmation before sensitive changes, and an audit trail naming the person behind every change — including when an operator is working inside a customer’s account. The admin side can be limited to your own addresses. Once you write an acceptable-use policy, customers agree to it before they use the panel, and each agreement is kept with the text they were shown.
A managed firewall whose changes revert on their own unless confirmed, so a rule cannot lock you out of your own server. Malware scanning with our own rules, and automatic abuse blocking that expires on its own and keeps an allowlist, so it catches attackers rather than customers.
When an account is deleted, the panel shows exactly what is left behind and lets you destroy it — the awkward question in a data-protection agreement, answered as a screen rather than as a promise. If a database, a login or a service cannot be removed, the account is not reported gone: it stays, and the panel says what is left.
Operations
Setup happens in a browser, over an encrypted connection from the first minute: the installer prints one link and the panel asks for what it needs. After that it looks after itself — health monitoring, per-site uptime checks, background work that is queued survives a restart, and sites brought back automatically after a reboot.
Updates are signed and verified before anything is applied, and one that fails
rolls itself back. Each release carries its known issues, and while the
server’s licence is current the Server page shows them for the version
running and the one on offer. A full API, and
a command-line client, opanelctl, for the work you would rather script.
Plans carry their own limits — disk, memory, CPU, bandwidth, monthly
transfer, mailboxes, send rate — and on Pro, resellers sell from an allowance
under their own name, logo and colour.
An account can have an address of its own from the server’s pool, for its sites and its outgoing mail, under the reverse name you set for it. On the paid tiers you can run extra containers beside an account — built from an image and a setup script, with the ports you list published — that its customer never sees, and the panel carries no OmegaPanel line: the sign-in screen and the page a suspended site answers carry your own words.
The panel speaks English, German and Bosnian, and its manual is built in: the ? beside a card opens the page that explains it. On the paid tiers, support is a ticket opened from inside the panel, and any access we need is something you grant inside that ticket.
Runs on Ubuntu 24.04 and 26.04 and Debian 13 on x86-64.