Linux Cloud Boxes no Dockup: 7 opções de distribuição

Os Linux cloud boxes oferecem um ambiente de sistema operacional que você configura por SSH. Eles são úteis para experimentos, software legado, serviços de sistema personalizados, build hosts e workloads cujo ciclo de vida não está naturalmente ligado a um repositório Git ou a uma imagem de container.

O Dockup oferece sete opções de imagem: Ubuntu 22.04, Ubuntu 24.04, Debian 12, Alpine 3.20, Fedora 40, AlmaLinux 9 e Rocky Linux 9.

Quando uma Linux box é melhor do que um serviço de container?

Escolha uma box quando o workload precisar de controle sobre o sistema operacional, e não apenas sobre um processo da aplicação.

Exemplos apropriados incluem:

• Instalar vários daemons do sistema.
• Testar pacotes do sistema operacional de forma interativa.
• Executar uma aplicação legada com configuração manual.
• Manter um build host ou host de automação.
• Reproduzir o ambiente Linux de um cliente.
• Executar ferramentas de longa duração que não estejam organizadas como um Git deploy.
• Criar um workspace SSH temporário e isolado.

Prefira um serviço do Dockup quando o workload for uma aplicação reproduzível com repositório, build, start command, health endpoint e necessidade de horizontal scaling.

Requisito	Linux box	Serviço de container
Personalização do sistema operacional com privilégios de root	Boa opção	Coloque as alterações no Dockerfile
Administração por SSH	Nativa	Interactive shell é PRO
Auto-deploy via Git push	Configuração manual	Integrado
Blue-green health gate	Implementação manual	Integrado
Imagem reproduzível	Requer runbook/script	Dockerfile/Nixpacks
Autoscaling	Não faz parte do modelo de box	Opção com Kubernetes
Testes rápidos de distribuição	Boa opção	A imagem base pode ser suficiente

Uma box troca a automação de deployment pela flexibilidade do sistema operacional.

Quais são as sete distribuições Linux disponíveis?

Consulte a lista atual de imagens:

dockup box images --json

Imagem	Ecossistema de pacotes	Motivo típico para escolher
ubuntu-22.04	APT	Compatibilidade de longo prazo
ubuntu-24.04	APT	Base Ubuntu LTS mais recente
debian-12	APT	Servidor geral conservador
alpine-3.20	apk	Ambiente pequeno baseado em musl
fedora-40	DNF	Ferramentas Linux mais recentes
almalinux-9	DNF	Compatibilidade com Enterprise Linux
rockylinux-9	DNF	Compatibilidade com Enterprise Linux

Escolha a distribuição de acordo com o ambiente compatível indicado pelo fornecedor do software. O Alpine usa musl em vez de glibc, o que pode afetar binários nativos pré-compilados. As variantes Enterprise Linux são úteis quando o software espera esse ecossistema de pacotes.

Registre o image slug exato. “Ubuntu” não é suficiente, porque as versões dos pacotes e as janelas de suporte diferem entre 22.04 e 24.04.

Como criar uma Linux cloud box?

Provisione a imagem informando nome, memória e CPU:

dockup box create \
  --project production \
  --image ubuntu-24.04 \
  --name build-host \
  --memory 2048 \
  --cpu 1 \
  --json

Este exemplo solicita 2.048 MB de RAM e 1 vCPU. Comece com requisitos medidos e ajuste com base no workload observado. O uso de CPU, RAM e disco é descontado do saldo do plano com medição por minuto.

O plano Free custa US$ 0 por mês, oferece US$ 10 de crédito inicial, um workspace, três databases e três deployments. Os planos pagos permitem recursos ilimitados em quantidade, mas o uso efetivo de compute continua consumindo o saldo incluído. O plano Pro recomendado custa US$ 20 por mês e inclui US$ 20 de crédito para uso.

A box criada se torna um recurso do projeto com um target estável, como production/build-host. Mantenha esse target no runbook.

Como obter e proteger o acesso SSH?

Solicite os detalhes da conexão:

dockup box ssh production/build-host --json

A resposta inclui host, porta, usuário e senha. Trate a senha como informação sensível. Armazene-a em um password manager aprovado, não a exiba na resposta de um agent e faça a rotação ou substituição do acesso de acordo com a política da organização.

Antes de se conectar:

1. Verifique o projeto e o box slug.
2. Confirme que o operador está autorizado.
3. Registre o objetivo da sessão.
4. Evite copiar secrets de produção para uma box descartável.
5. Mantenha o histórico de comandos e os logs livres de credenciais.
6. Feche caminhos de acesso e sessões que não estejam sendo usados.

O acesso SSH oferece amplos privilégios dentro da box. Um coding agent com a credencial poderia instalar pacotes, alterar serviços, expor portas ou excluir arquivos. Use o acesso de agents somente em uma tarefa revisada e bem delimitada, preservando um registro de auditoria fora do shell.

O artigo AI agent production guardrails apresenta o modelo de autonomia.

Como um workload SSH deve iniciar em uma Linux box?

Depois de obter o acesso SSH, configure a inicialização do processo com as ferramentas de sistema operacional compatíveis com a distribuição. Ubuntu, Debian, Fedora, AlmaLinux e Rocky Linux normalmente usam systemd; Alpine usa suas próprias convenções de gerenciamento de serviços.

A definição de inicialização deve indicar o executável, o diretório de trabalho, o usuário de execução, o ambiente necessário, a política de restart e o destino dos logs. Mantenha as credenciais fora do unit file ou do startup script e use caminhos absolutos para que o comportamento não dependa de um shell interativo.

Teste se:

• O workload inicia após um reboot sem login de um operador.
• O ambiente necessário está disponível sem exports exclusivos do shell.
• Os logs têm um local conhecido.
• O processo é executado pelo usuário pretendido.
• As falhas são observáveis.
• As atualizações não substituem dependências silenciosamente.

Para um único processo web com esses requisitos, um serviço de container baseado em Git talvez já ofereça um ciclo de vida melhor.

Como operar e recriar uma Linux box?

Trate cada comando manual como uma possível configuração divergente. Registre a configuração em um script ou processo de gerenciamento de configuração:

#!/usr/bin/env bash
set -euo pipefail

apt-get update
apt-get install -y git ca-certificates
mkdir -p /opt/app

Este exemplo genérico não é um comando do Dockup; ele ilustra como tornar a configuração da box repetível. Fixe ou documente as versões dos pacotes quando o workload exigir estabilidade.

Um runbook de box deve incluir:

• Image slug.
• CPU e memória solicitadas.
• Pacotes e repositórios instalados.
• Contas de usuário e política de SSH.
• Localizações no filesystem.
• Serviço de inicialização, executável e diretório de trabalho.
• Serviços expostos e sua autenticação.
• Método de backup dos dados.
• Procedimento de patch e reboot.
• Etapas de rebuild.
• Critérios de migração ou desativação.

Não presuma que o filesystem de uma box tenha o mesmo fluxo de snapshots de um volume de serviço do Dockup, a menos que esse fluxo esteja explicitamente configurado e seja compatível com o recurso. Planeje os backups para os dados e o software que realmente estão sendo executados ali.

Quando o workload deve ser migrado para um container?

Migre para um serviço de container quando:

• A configuração tiver se tornado um script estável.
• Um único processo da aplicação for o objetivo principal.
• As alterações no código-fonte precisarem ser feitas via deployment a partir do Git.
• Forem necessários releases sem downtime com health gate.
• O rollback precisar selecionar um ID de deployment anterior.
• Forem necessárias várias réplicas idênticas.
• A box estiver divergindo entre operadores.
• O acesso SSH estiver sendo usado apenas para fazer redeploy manualmente.

Converta a configuração em um Dockerfile, defina a porta da aplicação e o health path e faça primeiro o deployment de um serviço de preview ou não produtivo. Compare o comportamento antes de desligar a box.

O guia Nixpacks vs Dockerfile ajuda a escolher o novo método de build. Kubernetes vs Docker explica as opções de posicionamento no runtime.

Checklist para escolher uma Linux box

Uma decisão confiável sobre Linux cloud boxes responde a estas perguntas:

1. Qual dos sete image slugs corresponde ao suporte do fornecedor?
2. Por que o workload não pode usar um serviço normal?
3. Como as credenciais SSH são protegidas?
4. Como a configuração é reproduzida?
5. Onde ficam os logs e os dados persistentes?
6. Como os patches são testados?
7. Qual processo deve iniciar automaticamente?
8. Qual evento dispara a containerização ou a desativação?

Use a referência da CLI do Dockup para consultar os comandos atuais de box e a lista de imagens. Para workloads exclusivos do Windows, compare com Windows VM com RDP.

Controle a confiança em pacotes e repositórios

Uma box pode instalar qualquer pacote solicitado pelo operador, portanto as fontes dos pacotes fazem parte do limite de segurança. Use os repositórios assinados da distribuição, documente repositórios de terceiros e evite enviar scripts de rede não revisados diretamente para um shell com privilégios de root.

Registre a lista de pacotes após a configuração e compare-a durante a manutenção. Quando um agent sugerir a instalação de uma ferramenta, exija a fonte do pacote, a versão, a finalidade e o plano de remoção.

Avalie se a box ainda é necessária

Revise mensalmente a frequência das sessões SSH, as etapas de deployment manual, o requisito de uptime, o uso de recursos e os incidentes de divergência. Uma box que recebe releases frequentes de uma aplicação por SSH indica que precisa de um fluxo de serviço reproduzível.

Revise o consumo de CPU, RAM e disco da box em app.dockup.ai, junto com o runbook. Linux cloud boxes são valiosas quando o controle do sistema operacional é o requisito; operacionalmente, são caras quando apenas ocultam um deployment de aplicação não documentado.

Desative boxes temporárias de forma planejada

Uma box de testes deve ter um responsável e uma data de expiração definidos no momento da criação. Antes da desativação, exporte apenas os dados persistentes aprovados, remova as credenciais copiadas, preserve qualquer script de configuração reutilizável e confirme que nenhum DNS, job agendado ou runbook da equipe ainda depende do host.

Isso evita que um experimento curto se transforme em um servidor permanente sem patches.

Mantenha um responsável pelo acesso de emergência

Defina a pessoa ou equipe responsável quando o operador SSH habitual não estiver disponível. O responsável de backup deve saber onde as credenciais estão armazenadas e como verificar o target exato sem compartilhar senhas.

Registre a justificativa

Documente por que os Linux cloud boxes continuam sendo necessários.

Comece com um deployment verificável

Crie uma box pequena de não produção, automatize toda a configuração a partir de uma imagem limpa e defina antecipadamente quais evidências justificariam migrar o workload para um container.

Comece gratuitamente em app.dockup.ai. O plano Free custa US$ 0 por mês, inclui US$ 10 de crédito inicial e oferece um workspace, três databases e três deployments.

FAQ

Quais distribuições Linux as boxes do Dockup podem usar?

O Dockup oferece suporte a ubuntu-22.04, ubuntu-24.04, debian-12, alpine-3.20, fedora-40, almalinux-9 e rockylinux-9.

Como obtenho as credenciais SSH de uma Linux box?

Execute dockup box ssh com o target exato de projeto/box e --json; em seguida, armazene com segurança os detalhes de conexão retornados.

Como o software deve iniciar após a configuração do SSH?

Configure a inicialização com o service manager compatível com a distribuição selecionada e documente o executável, o diretório de trabalho, o usuário de execução, o ambiente, a política de restart e os logs.

Quando um serviço de container é melhor do que uma Linux box?

Use um serviço de container quando o workload for uma aplicação reproduzível que se beneficie de deployment via Git, health gates, rollback e autoscaling.

Como os recursos de uma Linux box são cobrados?

O consumo de CPU, RAM e disco é medido por minuto em relação ao saldo do plano. Por isso, monitore o uso real e evite alocações superdimensionadas.