Skip to content
Maintenance risk

Keep client websites secure before maintenance becomes an emergency.

Most client-site problems start quietly. Unolia checks every project on every sync, queues what it finds with the fix attached, and keeps the servers maintained on schedule.

Works with the providers your client sites already run on Amazon Route 53 Bento Bunny.net Cloudflare DigitalOcean Gandi GitHub GitLab Ionos Laravel Cloud Laravel Forge Mailgun Namecheap Oh Dear OVHcloud Ploi Porkbun Vultr
The real problem

Maintenance fails when it depends on memory.

The risky sites are usually the ones nobody has checked recently, not the ones already making noise. These are the problems that stopped waiting to be remembered.

The subdomain that pointed at nothing.

A campaign subdomain from two summers ago still delegated to a platform the client stopped paying. Nobody remembered it existed, which is exactly what made it dangerous. Unolia flagged the delegation mistake on sync, and the record was gone before anyone else found it.

Read more →

The monitor that was red for a month.

A form endpoint had been failing since February, in a dashboard nobody opened. In Unolia the monitor sits on the client's project, red where the whole team works. The fix took ten minutes once the problem had somewhere to be seen.

Read more →

The reboot nobody had to remember.

Kernel updates sat pending on 3 of the 8 servers. The maintenance run applied everything and rebooted only the 3 that asked for it, each step logged under the right client. The shell session nobody wanted to run at 23:00 stopped being a job.

Read more →
The value

Maintenance that runs like a system.

One queue for every client.

Everything the checks find lands in one queue, ranked by what matters: production, deliverability, client trust. Each issue explains what broke and why it matters, in words you can forward. When Unolia knows the fix, it comes attached, and the recheck confirms the site went back to green.

Servers that stay boring.

Updates run as structured recipes instead of late-night shell sessions. The run updates, reboots only the machines that ask for it and logs every step under the right client. The run history becomes the retainer’s proof, with no writing involved.

The coverage

Every quiet corner, checked on every sync.

DNS conflicts and delegated-subdomain mistakes, email authentication from SPF to DMARC, certificate rules, pending server updates and vulnerable dependencies. The checks run each time a project syncs, and every finding explains what broke and why it matters, with the fix attached when Unolia knows it.

Read more →
Proof

The discipline, in the product.

No impossible security promises. Checks, fixes, runs and records, shipping today.

DNS and email checks
Conflicts, duplicate or too-permissive SPF, missing DMARC and delegated-subdomain mistakes, caught on every sync.
Guided fixes
Supported issues carry their fix. You read what will change, apply it, and the recheck confirms it went green.
Dependency and vulnerability scans
Client repositories checked against published security advisories, with an issue opened on the affected project.
Server maintenance runs
Ubuntu updates and pending reboots as structured runs with confirmations and a log for every step.
Monitors in project context
Monitor state sits beside the deploys, providers and DNS of the site it watches, where red gets seen.
The shift

From checklist to operating system

Before

Maintenance depends on whoever remembers the checklist.

With Unolia

Project signals, issues and automations make one repeatable loop.

Before

The team discovers risk when a client complains.

With Unolia

The team reviews silent issues before they become visible incidents.

Before

Proof of maintenance lives in scattered consoles, if anywhere.

With Unolia

Issues found, fixes applied and runs logged, ready to show the client.

Make client-site maintenance visible.

Issues found, fixes applied, runs logged. The maintenance your retainer promises, visible at last.