Field notes

Building NasimLab: My Cloud Portfolio on DigitalOcean, Nginx, and Cloudflare

October 26, 2026 · 5 min read · Nasim Bayati

I’m working toward a cloud solutions architect role, and I wanted one place to show what I build and how I think about it. Course certificates say what I studied. A portfolio shows what I can actually design, run, and explain.

So I built NasimLab. I bought nasimlab.com from Namecheap, and I needed a server to host it. Instead of paying for a new one, I reused a DigitalOcean droplet I already had. I plan to move the site to AWS later, and that migration will be its own article.

This first article documents the hosting foundation: how a request reaches the site, what I verified, and what is still ahead.

At a glance

The current architecture

Namecheap is the registrar, and the domain’s DNS is managed in Cloudflare. Visitors connect to Cloudflare’s edge, and Cloudflare connects to my droplet over HTTPS. On the droplet, Nginx is configured for nasimlab.com and www.nasimlab.com and serves static files from a dedicated site directory.

flowchart LR
    V[Visitor] -->|HTTPS| C[Cloudflare edge]
    C -->|HTTPS, Full strict| O[DigitalOcean droplet]
    O --> N[Nginx virtual host]
    N --> F[Static HTML files]

Cloudflare’s SSL/TLS mode is set to Full (strict). Both legs of the trip are encrypted, and Cloudflare also validates the certificate on my server: it must be trusted, unexpired, and match the hostname. The weaker modes either leave the Cloudflare-to-server leg unencrypted (Flexible) or skip checking the server’s certificate (Full).

Right now the page is a small placeholder introducing my cloud, AI, and automation projects. The hosting foundation is running, and the portfolio and blog content are being built on top of it.

Separating the responsibilities

Each part of this setup has one job, which makes it easier to understand and troubleshoot:

Nginx’s server_name setting matters because one server can host several sites. Each hostname has to reach the correct virtual host and content directory. That’s why creating a DNS record alone doesn’t finish a new site: the server routing and HTTPS have to be configured too.

What I verified

On October 22, 2026, I ran a read-only review:

CheckObservation
Public HTTPS requestnasimlab.com returned HTTP 200 with Cloudflare response headers
HTTP requestRedirected to https://nasimlab.com/ with HTTP 301
Nginx configurationnginx -t completed successfully
Main-domain routingNginx configuration includes nasimlab.com and www.nasimlab.com
Origin certificateThe configured certificate lists the main domain and www hostname
Cloudflare TLS modeFull (strict), confirmed in the Cloudflare dashboard
Blog hostnameblog.nasimlab.com did not resolve yet (it went live on October 26; see below)

These checks show a working foundation. They do not show high availability, a tested backup-and-restore process, automatic certificate renewal, or a performance improvement.

The sampled HTML response reported CF-Cache-Status: DYNAMIC, which means Cloudflare did not serve that page from its cache. I can’t use that request as evidence that Cloudflare made the site faster.

The trade-off of using my own server

Running my own droplet means I learn Nginx, TLS, file permissions, and deployment by doing them myself. It also means I’m responsible for maintaining all of it.

A single droplet is a single point of failure. This is a personal portfolio, not a production system, and I’m not presenting it as highly available. The useful question is which improvements fit the site’s real needs and budget.

On cost, the droplet is $6.00 a month (about $0.009 an hour), and the Cloudflare Free plan costs nothing. The domain renewal is a separate yearly charge. For a static site, $6 a month is a fair price for the hands-on server practice. It’s also the baseline my AWS version will be compared against.

What comes next

Update, October 26, 2026: blog.nasimlab.com is live, and you’re reading it. I added a proxied DNS record in Cloudflare, a separate Nginx site for the new hostname, and a separate Let’s Encrypt certificate for it, issued with certbot the same way as the main site. Full (strict) validates it, a renewal dry run passed, and nasimlab.com was not touched.

The blog is built with Hugo, a static site generator, from Markdown files kept in Git. For now I build it locally and copy the output to the droplet. Next, I want a GitHub Actions pipeline that builds and deploys on every push, and I’ll document how deployment, rollback, and content updates work.

After that, I plan to move the site to AWS: S3 for storage, CloudFront for delivery, and an ACM certificate for HTTPS. That article will compare cost, effort, and reliability against this $6 droplet.

I also want to define a backup-and-restore process and test caching with repeatable requests. Those are planned improvements, not finished ones.

Why this belongs in my portfolio

The value of this project is the reasoning and evidence around it. A working page is just the beginning. Explaining the request path, knowing the limits of a test, and choosing the next improvement are what designing and operating cloud systems is about.

Future NasimLab articles will follow the same structure: a problem, an architecture, the decisions I made, how I verified them, and what I learned.

Technical references