How I built a toy infrastructure for my projects


I’ve been inhabiting online spaces on various social platforms long enough to see a few generations of these things come and go, and lost my fair share of writing in the shuffle.

So, I’d like to own my platform. It is small and modest, but it is mine, and I can monitor it and shape it to my liking. I think that’s nice. Feels like having a cabin in the woods on the web.

In this post I’ll share the brief details of what’s going on currently, and what I envision some easy wins to be, should they present themselves.


Right now, I have three main projects.

These are all sitting on the hostname. Main page is on www, and I have put the other two on subdomains: the git server is on git, and the blog on blog.

I use open source or my own source to provide the code (specifics provided below), host on Digital Ocean (DO), and have no CI or CD set up.

Infra + Platform

A few years ago I went to my domain name registrar and set up all traffic to go to Digital Ocean nameservers. I don’t remember who I did this through. Maybe it’s HostGator? I think I followed Digital Ocean documentation, so that part was easy enough.

So, that traffic goes to DO nameservers, and by using the DO control panel I manage the traffic for projects I host on their cloud.

For the sake of mirroring reality, let’s divide the projects into groups of the boxes they sit on.

For my pet box, I have:

From there, an nginx server reverse proxies traffic depending on subdomain. Requests to my main page get redirected to a node process, and requests to the blog get redirected to a static page sitting at /var/www/html.

For my second box, initialized (though not managed) by DO, I have:

Both of these boxes have 3 NS records pointing to DO nameservers with a TTL of 30 minutes.

Source Code

If working in software has taught me anything, it’s that spending a day or two looking for something that someone else has already solved for you could save weeks of building something only you can maintain, and that may distract you from your goal anyway. Tech is a tool, and the more time you can spend thinking about what you want to do with it, the better.

So, I’ve chosen:


I really like the model that let me set up the git server. It was initialized using Digital Ocean’s marketplace where the Gitea folks have provided for an easy button to get me up and running with a box that I could step into, configure, control, and modify. This process was both easy and able to give me maximum control of the end product, which is a split of responsibilities that I find inspiringly appealing. I might be modeling my own independent projects on this process in the future.

I recognize this is the one part that binds me to Digital Ocean – should I want to move ship I would need to get into the details of dumping contents of the database and updating contents in a new place. But here I think the ease of setup was worth that potential discomfort in the future.


For my blog, I used Hugo, a static site generator, and a ready-to-go theme made by a Hugo theme contributor, in order to prepare a blog site that would have customizability without tempting me to go in and edit all of the template files and html myself. If I had been less leisurely about it, I could have gotten the site set up in 30 minutes or an hour without content. As it was, I perused code formatting details for two hours, so it took me a bit longer to get all set up, with content, and with registering DNS records and fiddling with nginx config. It’s okay because I was in the mood for it. It was a very pleasurable experience, and I’ll be looking to such generators for use in professional settings more.

Choosing a blog and/or CMS stack was pretty overwhelming, so I decided to limit myself to static site generators that were in the well-worn path of popular solutions among developers. I looked at Gatsby, Hugo, and Jekyll. I considered the engines and templating languages, but weighted more heavily documentation, community support, and aesthetic of ready-to-go themes. I could still see myself moving to Gatsby, but opted for Hugo because of what I perceived as simplicity. This may limit me in the future should I choose to expand what the blog does, given I would probably have to learn Golang and this templating language, but for someone like me who gets distracted by possible bells and whistles, this was a desirable limitation.

Just a website

Finally, for my business-card main page, I have an awkwardly constructed static node server that is the remains of an idea for a web project that I decided not to complete. I scaled it back so I could return to regular life and regular work, so it’s a node process serving a static page with some light routing basically doing what an Apache server would do were these files in a correctly-named filepath. It’s fine. Mostly I’m glad that it’s a nice-looking website made from plain ol’ HTML and CSS.

Continuous Deployment

These are basically non-existent for each of these projects.

For the git server I will have to check the Marketplace and/or the Gitea docs to do an update, and follow that procedure. Until then, I am really fine with the version I have. If they implement a GitHub Actions knock off, I will update 100%.

For the other two projects, I ssh in, pull, restart processes and move files to where they ought to be. I haven’t had more than 3 updates over the past 3 years, so I haven’t much needed to improve on the model.


SSL Certificates

First of all, I’m bothered if I don’t have a green check, or padlock, or whatever browsers use to indicate a secure site.

Since I’m not asking anything of user data, it’s pretty safe already, but I don’t like the accusation of being “Not Secure” by Chrome. So fine, I give in.

Address CD

The biggest blocker to having a good quality of life will be this manual deployment process for the blog.

I have a few options there.

I don’t want to set up a CMS because I genuinely prefer writing in my code editor in markdown, and managing assets and other templates that Hugo makes easy to invent or modify from the theme I’ve installed.

Webhooks from the git server (or 3rd party integration) are the solution du jour, and for good reason, but I’m not too keen on adding a service dependency ($$$/how long will they be around?). I’m also digging this whole low-code life, and a webhook will be another thing I’ll need to monitor, maintain, fix and replace.

However, when I do convince myself that webhooks are fine, I’m thinking of using git submodules to create a separate repository that is the built assets from the site generator. On push to that repo, it could POST to a configured executable that would have my clone pull the files down and move to the appropriate location. I’d still prefer to have a GitHub Actions look-a-like that I could manage in the Gitea UI, but, this could be a close enough solution while that future awaits.

I could also use sftp or scp, but that pattern feels a little hidden in comparison to using git for version control and deploy management.

The important thing there is that I want to maintain two separate workflows – one for modifying source code, and one for deploying its built artefacts to production.

Google Analytics

Hugo config.toml files seem to support providing a GA id number. Of course I’d need to create the account GA-side, but that is about the easiest deployment of analytics I’ve ever seen, and an added bonus of choosing a static site.

Note to self: let the browser be the browser. You better be gaining a lot, if you go down the path of rewriting it.

It’s worth noting why I would want analytics. This is one thing I wish social media accounts gave the everyday user more insight into, and in fact I’m glad that Twitter offers analytics as a user-available product. Clicks are a reasonable metric, and I wouldn’t mind having them.

If I were to implement this, I’d need to do some cookie management stuff. This will be the biggest blocker, and mostly from the user experience path. GDPR has been a huge problem for web accessibility, and I’m not too keen on incorporating something that will introduce frustration. Clicks aren’t that worth it.

CDN Cacheing and Global Distribution, Load Balancing

If I implement these, it will be from an academic perspective.

Can we take it with us?

For the most part, yes.

The next step of increasing digital ownership would involve renting and maintaining hardware in a datacenter or even stashing some servers in the closet here in my house and working with my ISP to give them stationary IP addresses.

Given that my interest is mostly in owning my content, being writing and code, I’ve done the lion’s share of putting those in a place that I control.

Every few years some new paradigm comes around and shakes things up, and this way I have some assurance that this will all still be waiting for my cue.

Thanks for reading, and if you are considering doing similar projects, or are generally interested in moving your intellectual property somewhere you control, I hope you’ll read this and feel encouraged to do so. Whatever you’re wanting to do, it’s definitely possible. Look for solutions that have already addressed you need. Chances are, they can help you go further, quicker, while still giving you independence.