revs412@portfolio:~/notes/arm-vps-troubleshooting-for-dedicated-services$cat arm-vps-troubleshooting-for-dedicated-services.md

notes / Server Hosting

ARM VPS Troubleshooting for Dedicated Services

July 18, 2026updated July 25, 2026

Field notes from troubleshooting ARM-based VPS hosting for dedicated services, covering instance availability, boot issues, Docker architecture mismatches, runtime problems, and recovery checks.

Why This Note Exists

This note documents the troubleshooting process around hosting dedicated services on an ARM-based VPS.

The environment used an ARM/Ampere cloud instance for lightweight server hosting. The goal was to run dedicated services, including extension-enabled deployments without paying for a larger traditional x86 VPS.

The useful part of the project was not only getting a dedicated service online. It was learning how to debug the full stack when something breaks:

  • cloud instance state
  • boot volume
  • SSH access
  • provider limits
  • firewall/security rules
  • ARM vs x86 compatibility
  • Docker image architecture
  • native runtime libraries
  • dedicated service process logs
  • service restart behavior

This makes the note an infrastructure troubleshooting piece, not just a dedicated-service setup note.

Project Context

The server environment was an ARM VPS used for service hosting and experimentation.

The main workloads included:

  • hosted service server hosting
  • hosted service server hosting
  • ExtensionRuntime deployment
  • Docker attempts
  • architecture-specific runtime debugging
  • Linux service management
  • remote SSH administration

The VPS was attractive because ARM cloud instances can provide strong resources for low cost or free-tier style usage, but ARM also adds compatibility issues when software assumes x86.

What This Note Is Meant To Prove

  • cloud servers can fail at different layers
  • SSH failure does not always mean the server is deleted
  • instance state, boot volume, and network rules should be checked separately
  • ARM servers are useful but require architecture awareness
  • Docker images must match the CPU architecture unless emulation is used
  • dedicated services often depend on native libraries and runtime assumptions
  • logs matter more than guessing
  • a recovery checklist prevents panic when a server disappears or stops responding

Stack and Tools Used

Cloud Layer

  • ARM/Ampere VPS
  • cloud instance dashboard
  • boot volume
  • virtual network interface
  • public IP
  • security rules/firewall
  • serial/console access direction
  • instance stop/start/reboot checks

Operating System Layer

  • Linux
  • SSH
  • shell access
  • system logs
  • process checks
  • storage checks
  • firewall checks
  • service startup commands

Dedicated Service Layer

  • hosted service server
  • ExtensionLoader server direction
  • hosted service server
  • ExtensionRuntime
  • .NET runtime
  • server config files
  • logs and console output

Container Layer

  • Docker
  • platform/architecture selection
  • image compatibility
  • ARM vs amd64 behavior
  • container logs
  • volume mounts

Intended Build

The intended build was a stable ARM VPS used to host small dedicated services.

A finished environment should support:

  • SSH access
  • persistent dedicated service files
  • predictable startup commands
  • reachable public ports
  • backups
  • logs
  • restart process
  • architecture-compatible binaries/images
  • clear recovery steps when the instance fails

The setup does not need to be enterprise-grade. It needs to be understandable and recoverable.

The Main Problem Categories

Most issues fall into one of these groups:

1. Cloud/provider issue
2. Instance boot issue
3. Network/security rule issue
4. SSH/authentication issue
5. OS/runtime issue
6. Architecture compatibility issue
7. Dedicated service config issue
8. Docker/container issue

Treating every failure as “the server is broken” wastes time.

The right question is:

Which layer is failing?

Instance State Checks

The first step is checking the instance state in the cloud dashboard.

Important states:

running
stopped
stopping
starting
terminated
unavailable

If the instance is stopped, SSH will fail even if the files still exist.

If the instance is running but unreachable, the issue may be:

  • boot problem
  • firewall rule
  • public IP problem
  • SSH service problem
  • OS-level failure
  • network interface issue

If the instance is terminated, the next question is whether the boot volume still exists.

Boot Volume Checks

A stopped or unavailable instance does not always mean the data is gone.

The boot volume may still exist.

The recovery path can be:

check boot volume
attach boot volume to another instance if needed
mount it
recover service data files/configs
copy backups
rebuild server

For dedicated services, the most important data is usually:

  • service data files
  • config files
  • extension files
  • whitelist/ops/admin files
  • service scripts
  • backup archives

The compute instance is replaceable. The service data is the asset.

SSH Failure Does Not Mean One Thing

SSH can fail for many reasons.

Possible causes:

  • instance is off
  • public IP changed
  • security rule blocks port 22
  • OS firewall blocks SSH
  • SSH daemon not running
  • disk is full
  • CPU/RAM exhausted
  • wrong username
  • wrong key
  • network route problem
  • provider-side issue
  • boot failure

A good check order is:

instance state
public IP
security rules
ping/reachability if allowed
SSH port test
serial/console output
boot logs

Do not assume the SSH key is wrong until the infrastructure layer is checked.

Public IP and Security Rules

For dedicated services, two kinds of ports matter:

management port
dedicated service ports

Management:

22/tcp → SSH

service examples:

hosted service → TCP port depending on server config
hosted service  → TCP port depending on server config

The cloud security list/firewall must allow the intended inbound traffic.

The Linux firewall must also allow it if configured.

A port can be open in the cloud panel but blocked in the OS, or open in the OS but blocked by the cloud network rules.

Both layers matter.

Checking Local Listening Services

Before blaming the cloud firewall, check whether the service is listening locally.

Example:

ss -tulpn

or:

netstat -tulpn

This tells you whether the dedicated service or SSH daemon is actually listening.

If the service is not listening locally, public firewall rules will not help.

Checking Logs

Logs are the fastest way to stop guessing.

Useful checks:

journalctl -xe
dmesg | tail -100
df -h
free -h
ps aux | grep java
ps aux | grep ExtensionRuntime

For Docker:

docker ps -a
docker logs --tail 100 <container-name>

For a dedicated service, also check the server’s own log folder.

ARM vs x86 Compatibility

ARM VPS hosting has one major difference from normal x86 hosting:

not every binary or Docker image supports ARM

A common failure looks like:

exec format error

That usually means the binary inside the container or downloaded tool is for the wrong CPU architecture.

Example:

amd64 binary running on arm64 server

The fix is to use:

  • ARM-compatible binary
  • multi-arch Docker image
  • correct platform selection
  • emulation if acceptable
  • different install method
  • native server package where possible

Docker Architecture Problems

Docker does not magically make architecture problems disappear.

If a Docker image contains x86 binaries and the host is ARM, it may fail.

Typical error:

exec /entrypoint.sh: exec format error

or:

cannot execute binary file

Useful checks:

uname -m
docker image inspect <image-name>
docker run --rm <image-name> uname -m

If the host shows:

aarch64

then it is ARM64.

The container/image must support ARM64 unless emulation is configured.

Using amd64 Images on ARM

Sometimes an amd64 image can be forced with:

docker run --platform linux/amd64 ...

But this usually requires emulation support and can be slower or less reliable.

It can be useful for testing, but it is not always the cleanest long-term solution.

For dedicated services, performance and stability matter.

Prefer native ARM-compatible setup when possible.

SteamCMD and ARM Issues

Some dedicated service workflows depend on SteamCMD.

SteamCMD and some dedicated server binaries may assume x86/x86_64.

On ARM servers, this can create problems:

  • SteamCMD binary architecture mismatch
  • dedicated service binary not available for ARM
  • Docker image uses amd64 only
  • emulation needed
  • libraries missing
  • startup script fails before the service runs

The important lesson:

The VPS can be strong enough, but the software must support its CPU architecture.

Extension Runtime Issues

The hosted services with an ExtensionRuntime setup had its own runtime problems.

Possible issue categories:

  • .NET runtime mismatch
  • native library missing
  • launch script assumptions
  • architecture mismatch
  • server config path issue
  • extension build error
  • missing dependency
  • wrong working directory

A runtime/native library error is different from a extension code error.

For example:

FNA3D.so missing

is not the same kind of problem as:

C# override method signature is wrong

Separate environment/runtime errors from extension compilation errors.

ExtensionRuntime Build Direction

A custom extension build command had a shape like:

dotnet ExtensionRuntime.dll -build SurfaceProtection -tmlsavedirectory /home/opc/tml-arm/ExtensionRuntime

Problems here can come from:

  • wrong directory
  • wrong .NET runtime
  • missing native library
  • wrong ExtensionRuntime version
  • broken extension source
  • API mismatch
  • bad override signature

A build error should be read literally first. The compiler often points directly at the failing file and line.

hosted service Server Direction

hosted service on ARM is often easier than some other dedicated services because Java supports ARM well when the correct Java runtime is installed.

Main checks:

  • correct Java version
  • server jar exists
  • enough RAM
  • correct port
  • EULA accepted
  • extensions match server version
  • ExtensionLoader/loader versions match
  • service starts in correct directory
  • firewall allows the service port
  • backups exist

hosted service issues are more often config/extension/version problems than CPU architecture problems, though native extensions or wrappers can still matter.

Dedicated Service Data Preservation

For service hosting, the important directories should be easy to identify.

Examples:

/srv/dedicated-service/
/home/opc/tml-arm/ExtensionRuntime/

or whichever directory holds:

  • persistent data
  • extensions
  • configs
  • logs
  • backups
  • server scripts

A good server layout makes recovery easier.

If the VPS becomes unavailable, you should know exactly what needs to be copied from the boot volume.

Backup Direction

Backups matter more than instance size.

A basic backup plan should include:

service data files
config files
extension list
service scripts
environment files without public sharing
important logs if needed

Backups should be stored outside the instance if the service data matters.

At minimum:

local copy
separate volume
object storage
another server

A free or cheap VPS can disappear, fail, or be stopped. The data should not exist in only one place.

Provider Limits and Free-Tier Risk

Free-tier or low-cost cloud hosting can be useful, but it has risks:

  • capacity shortages
  • resource reclamation
  • account restrictions
  • unclear billing/free-tier messages
  • stopped instances
  • boot volume still present but compute unavailable
  • region availability changes
  • accidental paid resource creation

For a portfolio note, the important framing is not complaining about the provider.

The useful framing is:

designing recovery and verification steps for a low-cost ARM VPS environment

That shows infrastructure maturity.

Avoiding Accidental Paid Resources

When using cloud free-tier style resources, review:

  • instance shape
  • OCPU/RAM
  • boot volume size
  • block volumes
  • public IP type
  • load balancers
  • snapshots/backups
  • object storage
  • outbound bandwidth
  • region limits

The practical rule:

Know which resources cost money before creating them.

For small dedicated services, avoid adding random managed services unless required.

Serial Console / Recovery Console Direction

If SSH fails but the instance is still running, console access can help.

A serial/recovery console may reveal:

  • boot errors
  • disk full problems
  • failed services
  • network config errors
  • login prompts
  • kernel messages
  • stuck boot process

This is useful because SSH depends on the OS booting far enough and networking working.

Console access checks the server closer to the machine level.

Disk Full Problems

A full disk can break many things:

  • SSH login
  • package installs
  • dedicated service saves
  • logs
  • Docker
  • extension builds
  • service data backups

Check:

df -h

Docker can consume space with old images/containers.

Check:

docker system df

For dedicated services, service data backups and logs can grow over time.

RAM and CPU Pressure

Dedicated services can freeze or crash if resources are exhausted.

Check:

free -h
top
uptime

For Java/hosted service, memory flags matter.

For ExtensionRuntime/hosted service, extension count and service data activity matter.

For Docker, container limits may help prevent one service from consuming everything.

Firewall and Port Testing

A service needs three things:

process listening
OS firewall allows it
cloud firewall allows it

Testing sequence:

check local listening
check OS firewall
check cloud security rules
test from outside
check server logs during test

A port checker alone is not enough. The server logs confirm whether traffic reached the application.

Service Management

Dedicated services should not rely only on an interactive SSH session.

Better options:

  • systemd service
  • screen/tmux for manual testing
  • Docker container with restart policy
  • startup script with logs
  • documented start/stop commands

For long-running servers, a service manager is cleaner than manually starting the process after every reboot.

Common Mistakes

Assuming More Resources Means Fewer Problems

ARM instances can have good CPU/RAM, but compatibility still matters.

Treating Docker As Architecture-Neutral

Docker images still contain architecture-specific binaries.

Debugging service Config Before Checking Firewall

If no connection reaches the server, check network path first.

Thinking SSH Failure Means Data Is Lost

The boot volume may still be recoverable.

Running Everything Manually

Manual commands are fine for setup. Stable hosting needs repeatable start/restart/log workflows.

Not Backing Up persistent data

service data files are the most valuable part of the dedicated service.

Practical Troubleshooting Flow

A useful flow:

1. Is the cloud instance running?
2. Does it still have the expected public IP?
3. Are cloud security rules correct?
4. Does SSH port respond?
5. If SSH fails, check console/boot logs.
6. If SSH works, check disk/RAM/CPU.
7. Check whether the service endpoint is listening.
8. Check service logs.
9. Check architecture compatibility.
10. Test from outside.
11. Backup important data before risky changes.

This avoids jumping randomly between unrelated fixes.

Practical One-Line Checks

Architecture:

uname -m

Disk:

df -h

Memory:

free -h

Listening ports:

ss -tulpn

Docker containers:

docker ps -a

Recent system logs:

journalctl -xe --no-pager | tail -100

Docker logs:

docker logs --tail 100 <container-name>

Find large files:

du -h /home /srv /var 2>/dev/null | sort -h | tail -50

Check Java:

java -version

Check Wire/service process:

ps aux | grep -E 'java|hosted service|ExtensionRuntime'

Practical Decisions

Prefer native ARM when possible

Native ARM builds are cleaner than forcing amd64 emulation.

Keep persistent data backed up

The VPS can be rebuilt. The service data should not be disposable.

Separate provider problems from server problems

Cloud instance state, boot volume, and network rules are different layers.

Check logs before changing many things

Logs usually narrow the issue faster than guessing.

Document start commands

If the server needs a special command, write it down.

Use service managers

A reboot should not require remembering a long manual command.

What A Finished Setup Should Show

A strong finished ARM VPS dedicated-service setup should show:

  • instance shape and architecture documented
  • server directory layout
  • dedicated service start command
  • service manager or Docker run command
  • firewall/security rule list
  • backup path
  • recovery plan
  • architecture compatibility notes
  • logs location
  • restart instructions
  • service data files location
  • known limitations

Evidence Worth Capturing

Useful evidence for this note would include:

  • uname -m output
  • Docker architecture error
  • successful ARM-compatible container or native run
  • cloud instance state screenshot with sensitive data hidden
  • security rule screenshot
  • ss -tulpn showing service port
  • dedicated service console online
  • successful external connection
  • ExtensionRuntime build output
  • backup directory listing
  • recovery checklist

Technical Assumptions

This note assumes the server is an ARM64 VPS used for small dedicated-service hosting.

It assumes the operator has SSH access when the instance is healthy.

It assumes the server may be used for dedicated services, ExtensionRuntime, or similar small services.

It also assumes cloud provider behavior, free-tier limits, and instance availability should be treated as operational risks rather than ignored.

Key Risks

  • wrong CPU architecture for Docker image
  • missing native runtime libraries
  • no backups
  • boot volume exists but instance is unavailable
  • cloud security rules blocking service ports
  • OS firewall blocking traffic
  • SSH unavailable because the instance failed to boot
  • disk full from logs/backups/Docker images
  • service started manually and lost after reboot
  • extension/build errors confused with infrastructure errors
  • public ports open without understanding what listens behind them

Current State

This note represents the troubleshooting and operating lessons from using an ARM VPS for dedicated-service hosting.

The strongest value is the layered debugging approach:

cloud layer
network layer
OS layer
runtime layer
container layer
dedicated service layer
extension/plugin layer

Each layer can fail independently.

What This Note Does Not Claim

This note does not claim ARM VPS hosting is always better than x86 hosting.

It does not claim every dedicated service runs well on ARM.

It does not claim cloud free-tier resources are reliable enough for every production workload.

It documents practical troubleshooting for low-cost ARM dedicated-service hosting where compatibility, recovery, and backups matter.

Practical Takeaway

The useful lesson is:

On an ARM VPS, “the server does not work” is not one problem.

It could be:

provider state
boot failure
SSH/network issue
firewall rule
wrong architecture
missing runtime
Docker mismatch
service config error
extension build error
resource exhaustion

The fix is to debug by layer, preserve the service data files, and keep the deployment recoverable.