Server administration on the vServer is entirely our job. Anything you can’t do yourself in Plesk, we do via ticket — custom services, custom config, OS changes. Here’s what’s possible, what a good ticket looks like, and what you can’t get this way.
What we do on request
Typical requests:
Installing OS packages
- Specific Linux packages (
apt install <paket>) - Tools like
htop,iotop,tcpdump,nmap - CLI tools for your workflows
PHP extensions
- All standard extensions are already active
- Exotic / proprietary ones: sourceguardian, custom PHP extensions (the ionCube Loader is already standard with us)
- We install them on request
Apache/nginx custom directives
- Plesk writes the standard config
- Special directives (e.g. complex rewrite rules, custom headers) can be added in a Plesk-compliant way
- This goes through the Plesk API, so it survives the next Plesk update
Custom services / daemons
- Installing your own systemd units
- Custom cron jobs at OS level (not in Plesk)
- Background workers (e.g. Sidekiq, Celery, your own scripts)
Database tuning
- MySQL/MariaDB configuration for specific workloads
- Installing PostgreSQL as an additional DB engine (Plesk default is MariaDB)
- Redis / Memcached for caching
Firewall rules
- Opening specific ports (only when needed)
- IP whitelisting for admin areas
- Adjusting the Fail2Ban configuration
Mail server config
- Custom server-wide spam filter rules
- Mail quota adjustments beyond the Plesk default
- Adjusting TLS cipher suites for compliance
Performance tuning
- nginx/Apache worker configuration
- PHP-FPM pool tuning
- Kernel parameters (sysctl) for high load
How to write the ticket
What we need
-
What you want to achieve — the goal, not just the method
- Bad: “please
apt install certbot” - Better: “need wildcard SSL for *.yourdomain.com, the Let’s Encrypt DNS challenge can’t be done through Plesk”
- Bad: “please
-
Where you’re stuck — what you’ve already tried
- “The Plesk SSL toolkit only works with the HTTP challenge, I need the DNS challenge”
-
Time sensitivity — when you need it
- “Standard within 1 business day” or “urgent, by tomorrow”
Example of a good ticket
Subject: Install the sourceguardian PHP loader
Hi, I need the sourceguardian loader for PHP 8.2 and 8.3 on my vServer (Studio plan).
Background: a law firm’s custom CRM runs on sourceguardian-encoded files, otherwise the app won’t start.
Required: sourceguardian loader for PHP 8.2 and 8.3, both versions active.
Time: no rush, within the next 3 business days is fine.
We can get started right away.
Example of a bad ticket
Subject: PHP doesn’t work
please set up
We have to ask back, which costs both sides time.
How we work internally
What we do on every ticket:
- Analysis: does this fit the standard setup? Do we need custom config?
- Server snapshot before the change — rollback is possible at any time if something goes wrong
- Implement the change
- Test: does everything that ran before still run?
- Check the Plesk side: does your Plesk area stay consistent?
- Documentation: what we changed, in our internal docs for the server
- Ticket reply with a summary
For bigger changes: we check back with you first and agree on timing.
What we don’t do
Setting up frameworks outside Plesk
If you want Kubernetes, OpenStack or your own hypervisor setup on the vServer — this isn’t the right product for that. Bare metal or dedicated custom servers are a better fit.
Custom distributions
Arch, Gentoo, NixOS, Slackware — not available here. All Plesk vServers run AlmaLinux 10, no choice. That’s the only way updates, security patches and Plesk upgrades stay fully automatable.
Usage changes that break our terms of service
- Tor exit nodes
- Sending spam
- Crypto mining
- Illegal content
Obviously. We refuse these, possibly with account suspension.
Response times
| Request type | Standard response |
|---|---|
| Standard change (OS package, Plesk config) | within 1 business day |
| More complex change (custom service, DB tuning) | 1–3 business days |
| Emergency (site down, security incident) | prioritized above everything else — mark the ticket “Urgent” |
| Larger custom setups (own architecture) | by arrangement |
Please mark emergencies with “Urgent” / “Site down” in the ticket.
What you can do yourself directly (no ticket needed)
Directly in Plesk:
- Domains, mail, DBs
- Service plans and end customers (with the Web Host Edition)
- WordPress Toolkit, Softaculous, SiteJet
- Let’s Encrypt for domains
- Backup, restore, cloning
- Using the Plesk Migrator
- SSH (chrooted, per domain/subscription) for your own scripts
- Cron jobs in Plesk
- Choosing PHP versions per domain
- Managing DNS for end-customer domains
Common pitfalls
The ticket was vague — we build the wrong thing
If you don’t clearly say what you’re trying to achieve, we sometimes build the most obvious interpretation. For critical setups: better to agree on the approach in the ticket thread before the actual change.
Rollback after a mistake
We snapshot before every change. If something’s off after the change: a rollback is 5-10 minutes away.
Important: report problems promptly, not weeks later — snapshots only reach back a limited time.
Does a custom change survive Plesk updates?
If we build it “Plesk-compliant”: yes. Occasionally Plesk major updates break custom stuff — we check beforehand.
Without Plesk compliance: updates can break things. Hence our standard question: “Plesk-compliant or custom-only?”
Frequently asked questions
What do tickets cost? Standard tickets are included in the plan. For very involved custom setups (several hours of work, own architecture): a flat effort fee, and we tell you upfront.
Do you keep an internal log of what was changed on the server? Yes. Every change goes into internal docs. If questions come up, we can look up what happened on the server.
Can I get a “don’t-touch ticket” so you never touch the server unprompted? Yes. Tell us: “please no unsolicited OS updates, I’ll get in touch”. For security patches we override that (announced 24h in advance).
What if I really need full server access? Let’s talk. For specific compliance requirements or custom setups where tickets aren’t enough: a special solution with a dedicated server is possible. Effort and price by arrangement.
Can my end customers open tickets with you? By default, no. End customers are yours — you coordinate as the reseller. For larger escalations you can CC end customers on the ticket.
What if I’m not happy with your answer? Say so. We want the solution to fit. When opinions differ (“we recommend X, I want Y anyway”): we do Y, but note our concerns.
How fast is “emergency”? Real emergencies (site completely down, security incident) jump the queue ahead of everything else. We often see outages before your ticket arrives — our monitoring checks all services every 60 seconds and alerts us around the clock. We don’t promise a guaranteed response time.
What’s next
First login to the Plesk vServer
What you get after ordering, what the Plesk admin login looks like, which edition is installed and who's allowed to do what.
Service plans and end customers on the vServer
Managing end customers on the dedicated vServer with the Web Host Edition: service plans, sensible quotas, bulk workflows.
Using the Plesk Migrator
Clean server-to-server migration with the Plesk Migrator. Point it at the source server, the data comes over. Single site or bulk migration.
Performance monitoring on the vServer
What statistics Plesk shows, when to scale, how to find bottlenecks. Plus: what server monitoring we run in the background.