Your app always on, your tasks always on time

Turn your app into a service that starts with the server and schedule recurring scripts — backups, cleanups, health checks — from simple forms. See status, logs and the next run, and act in one click.

  • systemd services
  • Cron-style tasks
  • Logs included

See plans · Create a free account

Here's what it looks like in the panel

Services and scheduled tasks: systemd services
systemd services. Your app as a service, with a unit preview and live logs.

systemd and cron, minus the files

What keeps your app alive and your tasks on schedule.

  • Create services: Paste the .service content, with the option to start it as you create it. There are templates for Node.js, Python and Docker.
  • Safe by default: If the service fails to start after you create it, it removes itself. Before you edit an existing one, the file is backed up.
  • One-click control: Start, stop, restart, and enable or disable start on boot.
  • Clear status: Active, enabled at boot, PID, memory and uptime.
  • Protected: ssh, nginx, docker, mysql, postgresql and other critical services can't be deleted by mistake.
  • Scheduled tasks: Name, command and schedule; the .service and the .timer are generated for you. Shortcuts like hourly, daily or weekly.
  • Run now and pause: Test a task without waiting for its schedule, pause it without deleting it, or stop a run in progress.
  • Never skipped: Persistent timers: if the VPS was off at the scheduled time, the task runs at boot.
  • Logs for everything: The output of every service and task, from the panel.

Your app as a service

  1. Pick a template: Node.js, Python or Docker.
  2. Create and enable: It starts now and on every reboot.
  3. Schedule the recurring work: Backups, cleanups or health checks, each with its schedule.

How it works under the hood, and what to watch for

  • It doesn't use cron but systemd timers: for each task a .service and a .timer are generated. It is more verbose than a crontab line, and in exchange you get status, per-task logs, and the last and next run.
  • The schedule uses systemd's OnCalendar format, with shortcuts like hourly, daily or weekly. It is not cron syntax: daily in OnCalendar means midnight, which is not the same as cron's @daily.
  • Timers are persistent: if the VPS was off at the scheduled time, the task runs at boot. With cron, that run is simply lost.
  • If a service fails to start right after you create it, it removes itself and shows you the error, instead of leaving you a broken unit enabled at boot.
  • Before you edit an existing service, a copy of the original file is saved.
  • Critical services — ssh, nginx, docker, mysql, postgresql and others — are protected and can't be deleted by mistake from the panel.
  • Task commands use absolute paths, and scripts need the execute permission. It is the number one reason a task "does nothing": a timer's PATH is not your interactive PATH.
  • Names go in lowercase and without spaces.
  • Needs systemd running. Verified in production on Ubuntu 22.04 and compatible with 18.04, 20.04, 24.04 and 26.04; not available on 16.04.
  • Real root over SSH: the panel is a shortcut, not a cage. Anything it does with a button, you can also do by hand.

Or just ask Claude, ChatGPT or Cursor

Everything you see in the panel, your AI agent can do through the ArduMaker MCP server: with your authorization, within the scope you grant, and with every action audited. See what the MCP does

Frequently asked questions

How do I make my app start on its own when the VPS reboots?

You create its service and enable it with one click.

What happens if my service doesn't start when I create it?

It is rolled back and removed automatically, and you see the error.

Do I use cron syntax?

No, systemd's OnCalendar format, which also has shortcuts like daily or weekly.

Can I test a task without waiting?

Yes, with "run now".

What happens if the VPS was off at the scheduled time?

The task runs when it boots back up.

Why systemd timers and not cron?

Because each task ends up with its own status, its own logs and its next run in plain sight, and because timers are persistent: if the VPS was off at the scheduled time, the task runs at boot. With cron that run is lost and you never find out.

My task runs but does nothing, what do I check first?

The paths. A timer's PATH is not your interactive shell's: commands have to use absolute paths and scripts need the execute permission. After that, the task logs from the panel.

Can I pause a task without deleting it?

Yes, and you can also run it now without waiting for its schedule, or stop a run that is in progress.

Services that go well together

  • GitHub deploys: Link a repo and every push to your chosen branch updates your app on the VPS, with build and restart scripts.
  • Web terminal: Persistent in-browser terminals built on tmux that survive dropped connections and disconnects.
  • Automatic backups: A full live backup every week, the last 4 kept, and a final copy when you delete the VPS.

Less SSH, more time for your app Services and scheduled tasks in every VPS panel. See plans