Cloudcmd

Prerequisites

Before you deploy this image, you need:

• An AWS account subscribed to this product in AWS Marketplace
• An EC2 key pair in your target Region for SSH access
• A security group that allows inbound TCP 22 (SSH) from your IP, and TCP 443 (HTTPS) from your users. TCP 80 from your users is optional.

Recommended instance type: m5.large or larger.

Connecting to your instance

Connect over SSH as the default login user for your operating system variant. Use the key pair you launched with.

OS variant Login user Example

Ubuntu 24.04 ubuntu ssh -i your-key.pem ubuntu@<instance-public-ip>

Step 1 - Launch from the AWS Marketplace console

• Open the product page in AWS Marketplace. Choose Continue to Subscribe, then Continue to Configuration.
• Select the software version and your AWS Region. Choose Continue to Launch.
• Choose an instance type (m5.large or larger), your VPC subnet, the security group described above, and your EC2 key pair.
• Launch the instance. Wait for it to reach the running state with status checks passed.

Step 2 - Launch from the AWS CLI (alternative)

Replace the AMI ID, key name, security group and subnet with your own values.

aws ec2 run-instances \
  --image-id ami-xxxxxxxxxxxxxxxxx \
  --instance-type m5.large \
  --key-name your-key \
  --security-group-ids sg-xxxxxxxx \
  --subnet-id subnet-xxxxxxxx \
  --metadata-options "HttpTokens=required" \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=cloud-commander}]'

On first boot, Cloud Commander resolves the instance's public IPv4 address through IMDSv2. Launching with HttpTokens=required (IMDSv2) is fully supported.

Step 3 - Retrieve the per-instance admin credential

Each instance generates its own admin username and password on first boot and stores them in a root-only file. Connect over SSH and read the file:

sudo cat /root/cloudcmd-credentials.txt

The file shows the generated CLOUDCMD_USER, CLOUDCMD_PASS and CLOUDCMD_URL for this instance. Keep it secret. It is readable only by root (0600).

Step 4 - Sign in to the web file manager

Browse to your instance over HTTPS. Sign in with the credential from Step 3:

https://<instance-public-ip>/

Your browser warns about the self-signed certificate the first time. Accept the warning to continue, or install a real certificate (Step 10). Cloud Commander then prompts for the username and password. After you sign in, the two-panel file manager opens.

The two panels let you browse two locations at once, in the classic orthodox layout. The function key bar along the bottom exposes the file operations: view, edit, copy, move, make directory, delete and more.

Step 5 - Browse, upload and download files

Click a folder to open it. Each entry shows its size, date, owner and permissions.

• Upload: drag files onto the panel, or use the upload action, to copy files from your computer into the current folder.
• Download: select a file and download it, or open it directly.
• Copy / move: select items in one panel. Copy (F5) or move (F6) them to the folder open in the other panel.
• New folder / delete / rename: use the function key bar or the right-click menu.

All files live under the managed root /srv/cloudcmd on the dedicated data volume.

Step 6 - Edit files in the built-in editor

Select a text file and press F4 (Edit). The file opens in Cloud Commander's built-in Edward editor, with syntax highlighting for common formats.

Save with the editor's save action, then close the editor to return to the file panels. You can make quick edits to configuration and text files straight from the browser, with no SSH session or desktop needed.

Step 7 - Verify the service and the security posture

Confirm over SSH, at any time, that the appliance is healthy and correctly hardened.

Check that the services are running and note the pinned version:

systemctl is-active cloudcmd.service nginx.service cat /opt/cloudcmd/VERSION

Confirm four things: Cloud Commander is bound to loopback only, port 80 redirects to HTTPS, the health endpoint answers, and the API refuses unauthenticated access.

ss -tlnH | awk '{print $4}' | grep -E ':(443|8000)$' | sort -u curl -s -o /dev/null -w 'http_80_root=%{http_code}\n' http://127.0.0.1/ curl -sk -o /dev/null -w 'healthz=%{http_code}\n' https://127.0.0.1/healthz curl -sk -o /dev/null -w 'unauth_api=%{http_code}\n' https://127.0.0.1/api/v1/fs/

Expect 127.0.0.1:8000 as the only Cloud Commander listener (nginx owns 443), http_80_root=301, healthz=200 and unauth_api=401. The 401 shows that the API rejects any request without the admin credential.

Run the built-in self-test. It proves the full authenticated round trip: an unauthenticated request is refused, an authenticated listing succeeds, and a file uploaded through the API downloads back byte for byte.

sudo /usr/local/bin/cloudcmd-selftest

Confirm that authentication is on and that the terminal and console are disabled in the server configuration:

sudo grep -E '"(auth|terminal|console)"' /opt/cloudcmd/.cloudcmd.json

Step 8 - Change the file manager root (optional)

By default the file manager is confined to /srv/cloudcmd. To point it somewhere else, such as a mounted data disk, edit the root value in the server configuration and restart the service:

sudo nano /opt/cloudcmd/.cloudcmd.json
# change "root": "/srv/cloudcmd"
sudo systemctl restart cloudcmd

Make sure the cloudcmd system user can read the new location, and write to it if you want to save changes there.

Step 9 - Enable the built-in terminal or console (optional)

The built-in terminal and console give you a shell inside the browser. They are disabled by default because they are a powerful remote shell surface. If you understand the risk and want them, enable them behind the same authentication and TLS. Set the values in the configuration and restart the service:

sudo nano /opt/cloudcmd/.cloudcmd.json
# set "terminal": true and/or "console": true
sudo systemctl restart cloudcmd

Enable these only on instances restricted to trusted networks. They are as powerful as SSH.

Step 10 - Install a CA-signed certificate for a real domain (optional)

The image ships a per-instance self-signed certificate. For a production deployment, point a DNS name at the instance and install a CA-signed certificate. The simplest route is Let's Encrypt with certbot:

sudo apt-get update
sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d your-domain.example.com

certbot obtains the certificate and updates the nginx server block automatically. Alternatively, terminate TLS at an AWS Application Load Balancer or CloudFront in front of the instance.

Maintenance

• Services: sudo systemctl status cloudcmd nginx shows service health. Both restart automatically on failure.
• Logs: run sudo journalctl -u cloudcmd -e for the application and sudo journalctl -u nginx -e for the proxy.
• Updates: keep the operating system patched with sudo apt-get update && sudo apt-get upgrade. Cloud Commander itself is a global npm package (cloudcmd). Upgrade guidance is available from SecureAnyCloud support.
• Backups: back up the managed workspace at /srv/cloudcmd (its own EBS volume) with EBS snapshots or your preferred backup tooling.
• Data volume: the workspace volume is independently resizable. Grow it in the EC2 console and extend the filesystem without touching the operating system disk.

Support

SecureAnyCloud provides 24/7 technical support for this product by email and live chat, with a one-hour average response for critical issues. Support covers deployment, signing in, changing the file manager root, enabling the terminal safely, installing a CA-signed certificate and using a real domain, TLS termination with AWS load balancers, backups and scaling.

• Email: sales@secureanycloud.com
• Live chat: available 24/7

Deploy on AWS

Launch Cloud Commander on AWS with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com