Managed hosting vs raw VPS: what we actually do
Managed hosting only helps if the boundary is clear. Here is what PhotonSpark operates, what stays with your team, and how backups, access, email, uptime, and support fit together.
"Managed hosting" is one of those phrases that can mean almost anything. At one provider it means a control panel. At another it means someone will patch the server. At a third it means support will restore a backup if you ask nicely.
Here is the version we sell at PhotonSpark: we operate the hosting layer so your team can run the application without becoming a server maintenance team.
The boundary
We handle the infrastructure layer:
- Host operating system updates and security patching.
- Web server configuration for nginx, Caddy, or the agreed stack.
- TLS certificates and renewal.
- Monitoring for the host and public services.
- Backups for the managed environment.
- Restore support when the managed layer fails or data needs to be recovered.
- DDoS mitigation within the platform limits.
- Email setup when email hosting is part of the plan.
You still own the application layer:
- The code, CMS, plugins, themes, and business logic.
- Database schema and application migrations.
- Content changes and user permissions inside your app.
- Application-level analytics and product decisions.
- Bugs introduced by your own releases or third-party plugins.
That boundary matters. If the host is unhealthy, we fix it. If a plugin update breaks checkout, we help you investigate, but the root problem sits inside the application.
How this differs from a VPS
A raw VPS gives you a server and a password. That is useful if you know exactly what you are doing and want full control. It is also how small teams accidentally become responsible for patch windows, broken certificate renewals, backup scripts, firewall rules, disk alerts, and late-night incidents.
Managed hosting costs more because the quiet work is included. The point is not that a managed server is technically special. The point is that someone is accountable for the operating layer every week, instead of appearing only when a ticket arrives.
Access is not a cage
We do not lock customers out of their own systems. If the plan includes SSH access, you can get SSH access. For managed environments, we still ask that infrastructure-level changes go through support or at least get documented. It is hard to support a server if nobody knows what changed.
The practical rule is simple: use access when you need it, but keep the operational record clean. If you change a web server config, install a package, or adjust a cron job, tell us. That saves time during the next incident.
Backups and restores
Backups are only useful if restore has been tested and the retention period matches the risk. For managed hosting, the exact retention depends on the plan and workload, but the conversation should cover four points before launch:
- How often backups run.
- How long they are kept.
- Where they are stored.
- How fast a restore needs to happen.
A brochure line that says "daily backups" is not enough. A shop with orders every minute and a brochure site with five monthly edits do not need the same recovery plan.
Email, DNS, and migrations
Most hosting projects also touch email and DNS. We can host mailboxes, set up SPF, DKIM, and DMARC, and migrate mail over IMAP. If you prefer an external provider for mail, we can still configure the DNS records correctly.
For website migrations, we prefer a staged cutover. Copy the site, test it on a temporary hostname, verify mail and forms, lower DNS TTLs, then move traffic. Rushing the DNS step is how simple moves become messy.
Uptime language without theatre
We monitor the platform and publish service status at status.photonspark.com. The honest uptime conversation depends on architecture. A single hosted server can be very reliable, but it is still a single system. If you need stronger availability, the design changes: more than one node, external load balancing, replicated data, tested failover, and a different budget.
We will not pretend a single VM is the same thing as multi-region active-active infrastructure. If you need the latter, we will scope it separately.
Who should buy managed hosting
Managed hosting fits teams that want a stable environment, predictable support, and a clear owner for the infrastructure. It is usually a good fit for business websites, internal tools, small SaaS backends, CMS projects, ecommerce sites with moderate traffic, and companies that do not want a full-time sysadmin.
A raw VPS is better if your team wants to control every package, run unusual daemons, experiment freely, or operate the whole stack internally.
Neither choice is morally better. Pick the one that matches who will answer the incident at 02:00.
What to check before opening a ticket
If your site is down or slow, send facts rather than panic. These commands give support something useful to work with:
uptime
df -h
free -h
systemctl status nginx --no-pager || systemctl status caddy --no-pager
curl -I https://yourdomain.com
Check TLS and DNS from the outside:
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null
dig yourdomain.com A +short
dig yourdomain.com MX +short
If you have SSH access, include timestamps and recent logs:
journalctl --since "30 minutes ago" --no-pager | tail -200
sudo tail -100 /var/log/nginx/error.log
sudo tail -100 /var/log/nginx/access.log
A good support message looks like this:
Service: example.com managed hosting
Started: 2026-06-01 14:20 Europe/Bucharest
Impact: checkout returns 502 for all users
Last change: plugin update at 14:05, rolled back at 14:25, issue remains
Checks run: curl -I returns 502, disk 72% used, nginx active
Logs attached: nginx error log from 14:10-14:35
That is much faster to act on than "the site is broken." It also makes the boundary clearer: infrastructure, app release, DNS, TLS, or third-party dependency.