How I Automated Deployment For My Website

Published: Saturday, May 24, 2025

Updated: Saturday, May 24, 2025

One of the challenges I have faced with this site is simplifying the deployment process. In the past, as I’m sure you’ve guessed, I would have to manually get all my files onto my server. While this isn’t hard, it is time consuming. Here is the gist of how I saved myself a lot of time and future effort.

The Time Sinks.

First, here are the things that I think where the biggest time syncs:

  1. Everything is password protected with strong passwords.
    • I had to use a password manager to get into my server.
  2. I deployed rarely, meaning often I couldn’t remember all of my configurations.
  3. Permissions were restrictive.

All of these things combined added a lot time and, relatively speaking, a lot of effort. Particularly the security measures I have.

The Script

To solve the above issues, first I wrapped the steps into a script:

#!/bin/bash

if [ ! -f .env ]; then
    echo ".env file note found. Exiting."
    exit 1
fi

export $(grep -v '^#' .env | xargs)

# function to calculate new version number
function increment_version () {
  current_version=$(grep siteVersion config.toml | awk '{print $3}')
  new_version=$(echo "$current_version + 0.1" | bc)
  printf "%.1f" $new_version
}

new_version=$(increment_version)

sed -i "s/siteVersion = .*/siteVersion = $new_version/g" config.toml

hugo --minify --enableGitInfo

rsync -rtvzP "$WEBSITE_DIR/public/" deployer:$STAGING_DIR
ssh deployer "sudo mkdir -p $TARGET_DIR && \
              sudo find $TARGET_DIR -mindepth 1 -delete && \
              sudo cp -r $STAGING_DIR/* $TARGET_DIR && \
              sudo chown -R www-data:www-data $TARGET_DIR && \
              rm -rf $STAGING_DIR"

Configuration Changes

I obviously can’t explicitly show these changes because that is a security risk. However if you know your way around linux you will know what to do:

  1. Create a special user for deployment.
  2. Create a special ssh key for said user (on my deployment machine).
  3. Transfer key to server
  4. On the server give the user just enough permissions to transfer website files
    to where they need to be easily.
  5. The script takes care of the rest.

Conclusion

After implmementing the script and creating a slightly more sane server configuration in the context of deployment. A process that would take me quite some time was reduced to sub-1 minute on average. I’m not saying it took me hours originally, but it was a lot for what I was trying to do in my opinion.

Maybe now that it’s easier to update my site, i’ll be more likely to put out more content in the future. For example, I could write a post about how I think automation is lame except in certain cases—like this one. But that’s a conversation for another time.