Creating a custom domain for your Hashnode blog

UpdatedJanuary 23, 2023

Hashnode is a great platform for blogging, and creates a lot of sane defaults so you can get started quickly without having to make a lot of design choices, but you'll pretty quickly want to start making changes and making your blog your 'own'. One of the quickest, easiest, and slickest changes you can make is converting from the hashnode default domain, which can be a little clumsy to share, to your personal custom domain. To do this:

Register a domain with your provider of choice. I already had a top-level domain registered via AWS Route 53 (mivancic.com), and I remember that process being pretty quick and painless, especially if you're already working in AWS, but a domain from Cloudflare, Netcheap, or similar will work just fine
Select the custom URL your blog will redirect to. I opted for the simple blog.mivancic.com
Navigate to the Dashboard page for your Hashnode blog and select 'Domain'. You will be prompted with a window similar to the below:

Enter the desired domain into the field and select 'Update'
Once the custom domain has been update on Hashnode's end, you will still need to create a DNS record with your domain provider before your blog will be available from the new address. In my case, this record looked like this:

And that's about it. Hashnode warns you that it may take up to 24 hours for your CNAME record to propagate to Hashnode's servers and for them to issue the SSL cert they need to be able to route traffic accordingly, but in my experience with Route53, it was essentially instantaneous.

And with that, you've added a custom domain name to your blog. Have you done this for your own? Did you use a different DNS provider? How long did it take for your records to propagate accordingly? Let me know in the comments, I'd love to learn from your experiences.

Comments

Join the discussion

No comments yet. Be the first to comment.

More from this blog

Where We're Going, We Don't Need VMs: An example showing containers are Namespaced, not Virtualized

Sometimes, you just gotta go on an adventure. Take, for example, the below YAML manifest: apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: run: flux-capacitor powerNeeds: 121Gigawatts name: flux-capacitor spec: conta...

May 4, 20232 min read

Where We're Going, We Don't Need VMs: An example showing containers are Namespaced, not Virtualized

A Million Little Processes: Porting a Server-based AWS Infrastructure to a Containerized, Serverless Architecture utilizing ECS & Fargate

Like most stories, this one is at least a little bit about money. After I built my last project (as discussed here), I thought I could let that live on the internet for a while and coast off the free EC2 credits AWS allots to any account in the free...

Apr 5, 202310 min read

A Million Little Processes: Porting a Server-based AWS Infrastructure to a Containerized, Serverless Architecture utilizing ECS & Fargate

DNS Resolution errors in Docker containers

When first setting up Docker containers for the first time on a system, you may be able to build the hello-world container, pull images from Dockerhub, and even launch containers, but when you try to perform configuration that requires the container ...

Feb 27, 20232 min read

DNS Resolution errors in Docker containers

Building a Web App on AWS with EC2

When it comes to learning new skills, sometimes increasing your knowledge and remaining self-motivated remains the easy part. Becoming aware of what you don't know, understanding the framework under which these new skills can be applied in an enterpr...

Feb 17, 202314 min read

Route53 Hosted Zone delegation

When working in AWS, the typical advice is to avoid creating resources as the root user, both for security and to avoid confusion. It is typically recommended instead to utilize AWS Organizations to create a new account for every AWS project (I perso...

Feb 13, 20232 min read

Dispatches from /dev/null

8 posts

Command Palette

Comments

More from this blog