Provision and configure a server
DeployCrate separates creating a server record from provisioning cloud infrastructure. The server record stores configuration and encrypted credentials. Provisioning creates the VM in your cloud account, then configuration turns that fresh VM into a host that DeployCrate can operate safely.
The important split is:
- Provisioning talks to the provider API, creates provider SSH keys, creates the VM, stores the provider server ID, and waits for the server to become reachable.
- Configuration connects to the new server over SSH, creates the long-lived Linux users, installs the required system packages and services, hardens SSH, starts crate-operator, and validates that the operator is healthy.
Before provisioning
Start with the cloud account that should own the server. Create a provider token in Hetzner or DigitalOcean, then add it to DeployCrate from the New Server flow or the Provider Credentials area. DeployCrate uses this token only for infrastructure operations such as creating SSH keys, creating servers, reading server status, and storing the external server identifier.
Then create a server and choose:
- region or location
- server type
- provider server size
- SSH port
- server name
The provisioning screen writes these choices to the server before the background job starts. The first server should normally be an Application server. Other server types may appear in the product as the platform expands, but application servers are the path used for regular web app deployments.
Provisioning phases
Provisioning has two phases, and the setup status page records progress for each attempt. This matters when something fails: a provider error, a DNS update problem, an SSH connection issue, and an operator validation issue all point to different fixes.
Cloud infrastructure
DeployCrate asks the provider to create the VM, registers the SSH keys needed for setup and recovery, waits for the provider to report the server as ready, stores the assigned IPv4 and IPv6 addresses when available, and points the operator hostname at the server.
During this phase, the server still behaves like a fresh cloud VM. DeployCrate uses root SSH only as a bootstrap channel so it can create the managed users and install the platform services.
Host configuration
DeployCrate connects over SSH and applies a fixed setup plan. The plan installs baseline packages, log retention, Docker, Caddy, fail2ban, node_exporter, host safety timers, and the crate-operator systemd services.
At the end of configuration, DeployCrate hardens SSH and validates the operator health endpoint. Root SSH is no longer part of normal operation after this point. Routine deployment work goes through crate-operator, and human access goes through the customer-owned admin account.
Linux accounts
Every managed server gets separate accounts for different responsibilities.
| Account | Purpose |
|---|---|
| admin | Customer-owned account for human access and break-glass operations. |
| crate-operator | Non-login service account used for routine DeployCrate operations. |
| crate-operator-emergency | Restricted recovery account for restarting operator services. |
The operator account uses a narrow sudo policy instead of full root access. It can manage application units, Docker, selected files under DeployCrate-owned paths, WireGuard-related files, selected package update commands, and read operational logs.
SSH access after provisioning
After provisioning succeeds, DeployCrate shows the connection details you need for direct server access. Store the private key in your local SSH directory and restrict the file permissions before using it.
mkdir -p ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/deploycrate-example
Then add a host entry to ~/.ssh/config so you do not need to remember the username, IP address, port, or key path.
Host deploycrate-example
HostName 203.0.113.10
User admin
Port 22
IdentityFile ~/.ssh/deploycrate-example
IdentitiesOnly yes
Replace deploycrate-example, 203.0.113.10, 22, and the key filename with the values shown for your server. You can then connect with:
ssh deploycrate-example
Use the admin account for human maintenance and break-glass work. Do not change DeployCrate-owned service files, Caddy routes, application units, Docker labels, or operator-managed directories unless you are deliberately recovering a broken host; DeployCrate may replace those during future deployments or maintenance.
Setup status and retrying
Provisioning status is stored per setup attempt. If a step fails, open the failed step first and read its events before creating a replacement server.
Common failure points are:
| Failure area | What it usually means |
|---|---|
| Provider provisioning | The provider token is missing a permission, the selected region or size is unavailable, or the provider rejected the request. |
| SSH connection | The VM is not reachable yet, the provider assigned an unexpected address, the SSH port is blocked, or the bootstrap key was rejected. |
| Host setup script | A package install, system service, firewall rule, or user creation step failed on the host. |
| Operator validation | The server was configured, but crate-operator did not start or did not answer the health check. |
Retrying should resume from persisted setup state instead of requiring a new server record. If the provider already created the VM, check the existing setup events before deleting anything in the cloud provider console.
Security posture
DeployCrate provisions hosts so root SSH access is not part of normal operation after setup. The customer admin account remains available for ownership and recovery, while routine deployment operations go through the operator API and service account.
The result is a server you still own in your provider account, with DeployCrate responsible for repeatable setup, deployment operations, Caddy routing, operator updates, and the managed application lifecycle.