O seu app sempre ligado, as suas tarefas sempre na hora

Transforme o seu app num serviço que sobe sozinho com o servidor e agende scripts periódicos —backups, limpezas, health checks— por formulários. Veja o status, os logs, a próxima execução e aja com um clique.

  • Serviços systemd
  • Tarefas tipo cron
  • Logs incluídos

Ver planos · Criar conta grátis

É assim no painel

Serviços e tarefas agendadas: Serviços systemd
Serviços systemd. A sua app como serviço, com pré-visualização do unit e logs ao vivo.

systemd e cron, sem os arquivos

O que mantém o seu app vivo e as suas tarefas em dia.

  • Criar serviços: Você cola o conteúdo do .service, com opção de iniciá-lo já na criação. Há modelos para Node.js, Python e Docker.
  • Seguro por padrão: Se o serviço falhar ao subir depois de criado, ele é removido sozinho. Antes de editar um existente, é feito um backup do arquivo.
  • Controle com um clique: Iniciar, parar, reiniciar e habilitar ou desabilitar o início automático.
  • Status claro: Ativo, habilitado no boot, PID, memória e tempo ligado.
  • Protegidos: ssh, nginx, docker, mysql, postgresql e outros serviços críticos não podem ser removidos por engano.
  • Tarefas agendadas: Nome, comando e horário; o .service e o .timer são gerados sozinhos. Atalhos como hourly, daily ou weekly.
  • Executar agora e pausar: Você testa uma tarefa sem esperar o horário dela, pausa sem apagar ou interrompe uma execução em curso.
  • Nunca pula: Timers persistentes: se o VPS estava desligado na hora agendada, a tarefa roda ao subir.
  • Logs de tudo: A saída de cada serviço e de cada tarefa, pelo painel.

O seu app como serviço

  1. Escolha um modelo: Node.js, Python ou Docker.
  2. Crie e habilite: Sobe agora e a cada reinício.
  3. Agende o que é periódico: Backups, limpezas ou health checks com o seu horário.

Como funciona por baixo, e o que levar em conta

  • Não se usa cron, e sim timers do systemd: para cada tarefa são gerados um .service e um .timer. É mais verboso que uma linha de crontab, e em troca você ganha status, logs próprios por tarefa e a última e a próxima execução.
  • O horário usa o formato OnCalendar do systemd, com atalhos como hourly, daily ou weekly. Não é a sintaxe do cron: daily no OnCalendar é meia-noite, não é a mesma coisa que um @daily do cron.
  • Os timers são persistentes: se o VPS estava desligado na hora agendada, a tarefa roda ao subir. Com cron, essa execução simplesmente se perde.
  • Se um serviço falha ao subir logo depois de criado, ele é removido sozinho e o erro é mostrado, em vez de deixar para você uma unidade quebrada habilitada no boot.
  • Antes de editar um serviço existente, uma cópia do arquivo original é guardada.
  • Os serviços críticos —ssh, nginx, docker, mysql, postgresql e outros— estão protegidos e não podem ser removidos por engano pelo painel.
  • Os comandos das tarefas usam caminhos absolutos, e os scripts precisam de permissão de execução. É a causa número um de uma tarefa "não fazer nada": o PATH do timer não é o seu PATH interativo.
  • Os nomes vão em minúsculas e sem espaços.
  • Precisa de systemd rodando. Verificado em produção no Ubuntu 22.04 e compatível com 18.04, 20.04, 24.04 e 26.04; no 16.04 não está disponível.
  • Root real por SSH: o painel é um atalho, não uma jaula. Tudo o que ele faz com um botão você também pode fazer à mão.

Você também pode pedir ao Claude, ChatGPT ou Cursor

Tudo o que você vê no painel o seu agente de IA pode fazer pelo servidor MCP da ArduMaker: com a sua autorização, com o alcance que você der e com cada ação auditada. Ver o que o MCP faz

Perguntas frequentes

Como faço o meu app subir sozinho quando o VPS reinicia?

Você cria o serviço dele e habilita com um clique.

O que acontece se o meu serviço não subir na criação?

Ele é revertido e removido automaticamente, e você vê o erro.

Uso sintaxe de cron?

Não, o formato OnCalendar do systemd, que ainda tem atalhos como daily ou weekly.

Posso testar uma tarefa sem esperar?

Sim, com "executar agora".

O que acontece se o VPS estava desligado na hora agendada?

A tarefa é executada quando ele voltar a subir.

Por que timers do systemd e não cron?

Porque cada tarefa fica com o seu status, os seus logs e a sua próxima execução à vista, e porque os timers são persistentes: se o VPS estava desligado na hora agendada, a tarefa roda ao subir. Com cron essa execução se perde e você nem fica sabendo.

Minha tarefa roda mas não faz nada, o que eu olho primeiro?

Os caminhos. O PATH de um timer não é o do seu shell interativo: os comandos têm que ir com caminho absoluto e os scripts precisam de permissão de execução. Depois, os logs da tarefa pelo painel.

Posso pausar uma tarefa sem apagar?

Sim, e também executá-la agora sem esperar o horário dela, ou parar uma execução que está rodando.

Serviços que costumam andar juntos

  • Deploy do GitHub: Vincule um repo e cada push na branch escolhida atualiza o seu app no VPS, com scripts de build e reinício.
  • Terminal web: Terminais persistentes no navegador sobre tmux, que sobrevivem a quedas e desconexões.
  • Backups automáticos: Cópia completa semanal a quente, as últimas 4 guardadas e uma cópia final ao excluir o VPS.

Menos SSH, mais tempo para o seu app Serviços e tarefas agendadas no painel de cada VPS. Ver planos