For one of my exchange courses at Murdoch University (ICT171, 2025), the assignment was simple on paper: put a real service online on a cloud VM. The service to put online was Nextcloud. What I learned had almost nothing to do with Nextcloud itself, and everything to do with the distance between "it runs on my machine" and "it's a service other people can actually reach."

What I actually deployed

The whole thing lives on a single cloud VM — a droplet running Ubuntu 22.04. Nextcloud and its database run in containers with Docker (20.x or newer) and Docker Compose. Nothing exotic: docker compose up -d brings the stack up.

The part that felt grown-up was configuration through a .env file — the Nextcloud admin account and the database credentials never live in the compose file itself. It's a small habit, but it's the difference between a demo and something you can hand off or rebuild without leaking secrets into version control.

DNS and TLS are where "localhost" ends

On my laptop, everything answers on localhost and I never think about it. In public, nobody types an IP address. I set an A record for cloud.alex-abriel.com pointing at the droplet's IP, then actually verified it resolved instead of assuming — dig and nslookup became part of the loop:

dig +short cloud.alex-abriel.com

Then the certificate. I ran Nginx as a reverse proxy in its own container. Port 80 doesn't serve the app — it does two jobs: expose the ACME challenge path so Let's Encrypt can prove I own the domain, and redirect everything else to HTTPS.

server {
    listen 80;
    server_name cloud.alex-abriel.com;

    location /.well-known/acme-challenge/ {
        # served for Let's Encrypt validation
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

That 301 line is the whole point of a public service in one instruction: no plaintext, ever.

Backups, because a service you can't restore isn't one

The last thing that separated this from a toy was a documented backup script. It's easy to feel finished when the login page loads over HTTPS. But a service holding files is only as real as your ability to bring it back after the VM dies. Writing the backup down — and writing down how to use it — was part of the assignment I'm actually glad was graded.

What an exchange course made me do

I could have read about DNS, reverse proxies and TLS for a long time without ever wiring them together. ICT171 forced the whole chain in one go: VM, containers, domain, certificate, proxy, backups, and full documentation on top — installation notes, the networking setup, even a PDF write-up.

The takeaway I keep coming back to: "it works" and "it's a service" are two different claims. The gap between them is DNS resolving, a valid certificate, a proxy that refuses plaintext, and a documented backup you can actually run. None of it is glamorous. All of it is the actual job.