Linux Cloud Boxes on Dockup: 7 Distribution Options
Linux cloud boxes on Dockup: choose seven distributions, provision CPU and RAM, retrieve SSH access, configure the operating system, and compare containers.
Linux cloud boxes provide an operating-system environment you configure over SSH. They are useful for experiments, legacy software, custom system services, build hosts, and workloads whose lifecycle is not naturally tied to a Git repository or container image.
Dockup supports seven image choices: Ubuntu 22.04, Ubuntu 24.04, Debian 12, Alpine 3.20, Fedora 40, AlmaLinux 9, and Rocky Linux 9.
When is a Linux box better than a container service?
Choose a box when the workload needs control over the operating system rather than only an application process.
Appropriate examples include:
- Installing several system daemons.
- Testing operating-system packages interactively.
- Running a legacy application with manual setup.
- Maintaining a build or automation host.
- Reproducing a customer Linux environment.
- Executing long-lived tools not organized as a Git deploy.
- Creating a temporary isolated SSH workspace.
Prefer a Dockup service when the workload is a reproducible application with a repository, build, start command, health endpoint, and horizontal scaling needs.
| Requirement | Linux box | Container service |
|---|---|---|
| Root-style OS customization | Strong fit | Put changes in Dockerfile |
| SSH administration | Native | Interactive shell is PRO |
| Git push auto-deploy | Manual setup | Built in |
| Blue-green health gate | Manual design | Built in |
| Reproducible image | Runbook/script needed | Dockerfile/Nixpacks |
| Autoscaling | Not the box model | Kubernetes option |
| Quick distro testing | Strong fit | Base image may suffice |
A box trades deployment automation for operating-system flexibility.
Which seven Linux distributions are available?
Query the current image list:
dockup box images --json
| Image | Package ecosystem | Typical reason to choose |
|---|---|---|
ubuntu-22.04 | APT | Long-lived compatibility |
ubuntu-24.04 | APT | Newer Ubuntu LTS base |
debian-12 | APT | Conservative general server |
alpine-3.20 | apk | Small, musl-based environment |
fedora-40 | DNF | Newer Linux tooling |
almalinux-9 | DNF | Enterprise Linux compatibility |
rockylinux-9 | DNF | Enterprise Linux compatibility |
Match the distribution to the software vendor’s supported environment. Alpine uses musl rather than glibc, which can affect prebuilt native binaries. Enterprise Linux variants are useful when software expects that package ecosystem.
Record the exact image slug. “Ubuntu” is insufficient because package versions and support windows differ between 22.04 and 24.04.
How do you create a Linux cloud box?
Provision the image with a name, memory, and CPU:
dockup box create \
--project production \
--image ubuntu-24.04 \
--name build-host \
--memory 2048 \
--cpu 1 \
--json
This example requests 2,048 MB of RAM and 1 vCPU. Start with measured requirements and adjust from observed workload. CPU, RAM, and disk use are deducted from the plan balance with per-minute measurement.
The Free plan is $0 per month with $2.50 starting credit, one workspace, three databases, and three deployments. Paid plans allow unlimited resources by count, while actual compute still consumes the included balance. The recommended Go plan is $20 per month with $20 usage credit.
The created box becomes a project resource with a stable target such as production/build-host. Keep that target in the runbook.
How do you retrieve and protect SSH access?
Request connection details:
dockup box ssh production/build-host --json
The response includes the host, port, user, and password. Treat the password as sensitive. Store it in an approved password manager, do not print it in an agent answer, and rotate or replace access according to the organization’s policy.
Before connecting:
- Verify the project and box slug.
- Confirm the operator is authorized.
- Record the purpose of the session.
- Avoid copying production secrets onto a disposable box.
- Keep command history and logs free of credentials.
- Close unused access paths and sessions.
SSH access creates broad power inside the box. A coding agent with the credential could install packages, alter services, expose ports, or delete files. Use agent access only under a reviewed, narrow task and preserve an audit record outside the shell.
The AI agent production guardrails article provides the autonomy model.
How should an SSH workload start on a Linux box?
After retrieving SSH access, configure process startup with the distribution’s supported operating-system tools. Ubuntu, Debian, Fedora, AlmaLinux, and Rocky Linux commonly use systemd; Alpine uses its own service-management conventions.
The startup definition should state the executable, working directory, runtime user, required environment, restart policy, and log destination. Keep credentials outside the unit file or startup script and use absolute paths so behavior does not depend on an interactive shell.
Test:
- The workload starts after a reboot without an operator login.
- Required environment is available without shell-only exports.
- Logs have a known location.
- The process runs under the intended user.
- Failure is observable.
- Updates do not silently replace dependencies.
For a single web process with these requirements, a Git-based container service may already provide a better lifecycle.
How should a Linux box be operated and rebuilt?
Treat every manual command as potential configuration drift. Capture setup in a script or configuration-management process:
#!/usr/bin/env bash
set -euo pipefail
apt-get update
apt-get install -y git ca-certificates
mkdir -p /opt/app
This generic example is not a Dockup command; it illustrates how to make box configuration repeatable. Pin or document package versions where the workload requires stability.
A box runbook should include:
- Image slug.
- Requested CPU and memory.
- Installed packages and repositories.
- User accounts and SSH policy.
- Filesystem locations.
- Startup service, executable, and working directory.
- Open services and their authentication.
- Data backup method.
- Patch and reboot procedure.
- Rebuild steps.
- Migration or retirement criteria.
Do not assume a box filesystem has the same snapshot workflow as a Dockup service volume unless that workflow is explicitly configured and supported for the resource. Design backups for the data and software actually running there.
When should the workload move into a container?
Move toward a container service when:
- Setup has become a stable script.
- One application process is the main purpose.
- Source changes should deploy from Git.
- Health-gated zero-downtime releases are needed.
- Rollback should select a previous deployment ID.
- Several identical replicas are required.
- The box is drifting between operators.
- SSH access is used only to redeploy manually.
Convert the setup into a Dockerfile, define the application port and health path, and deploy a preview or non-production service first. Compare behavior before shutting down the box.
The Nixpacks vs Dockerfile guide helps choose the new build method. Kubernetes vs Docker explains the runtime placement options.
Linux box selection checklist
A reliable Linux cloud boxes decision answers:
- Which of the seven image slugs matches vendor support?
- Why can the workload not use a normal service?
- How are SSH credentials protected?
- How is setup reproduced?
- Where are logs and durable data?
- How are patches tested?
- What process should start automatically?
- What event triggers containerization or retirement?
Use the Dockup CLI reference for the current box commands and image list. For Windows-only work, compare Windows VM with RDP.
Control package and repository trust
A box can install any package the operator requests, so package sources become part of the security boundary. Use the distribution’s signed repositories, document third-party repositories, and avoid piping unreviewed network scripts directly into a root shell.
Record the package list after setup and compare it during maintenance. When an agent proposes installing a tool, require the package source, version, purpose, and removal plan.
Measure whether the box is still justified
Review SSH session frequency, manual deployment steps, uptime requirement, resource use, and drift incidents every month. A box that receives regular application releases through SSH is signaling that it wants a reproducible service workflow.
Review the box's CPU, RAM, and disk consumption in app.dockup.ai alongside the runbook. Linux cloud boxes are valuable when OS control is the requirement; they are expensive operationally when they merely hide an undocumented application deployment.
Retire temporary boxes deliberately
A test box should have an owner and an expiry date at creation. Before retirement, export only approved durable data, remove copied credentials, preserve any reusable setup script, and confirm that no DNS, scheduled job, or team runbook still depends on the host.
This prevents a short experiment from becoming an unpatched permanent server.
Keep an emergency access owner
Name the person or team responsible when the normal SSH operator is unavailable. The backup owner should know where credentials are stored and how to verify the exact target without sharing passwords.
Keep the rationale
Document why Linux cloud boxes remain necessary.
Start with a verifiable deployment
Create a small non-production box, script its complete setup from a clean image, and decide in advance what evidence would justify moving the workload into a container.
Start free at app.dockup.ai. The Free plan is $0 per month, includes $2.50 in starting credit, and supports one workspace, three databases, and three deployments.
FAQ
Which Linux distributions can Dockup boxes use?
Dockup supports ubuntu-22.04, ubuntu-24.04, debian-12, alpine-3.20, fedora-40, almalinux-9, and rockylinux-9.
How do I get SSH credentials for a Linux box?
Run dockup box ssh with the exact project/box target and --json, then store the returned connection details securely.
How should software start after SSH setup?
Configure startup with the selected distribution’s supported service manager and document the executable, working directory, runtime user, environment, restart policy, and logs.
When is a container service better than a Linux box?
Use a container service when the workload is one reproducible application that benefits from Git deployment, health gates, rollback, and autoscaling.
How are Linux box resources charged?
CPU, RAM, and disk consumption are measured per minute against the plan balance, so monitor actual use and avoid oversized allocations.