← Back to Articles
●•May 29, 2026•4 min read

How I Built My First DevOps Portfolio (Next.js + Payload + Neon + Render)

Introduction

As a freelance DevOps engineer, I spend most of my days in the terminal, writing YAML files, configuring CI/CD pipelines, and making sure other people’s apps run smoothly. But recently, I faced a different kind of challenge: I needed to build my own portfolio website. When you’re freelancing, your portfolio isn't just a resume—it’s your storefront. I needed something fast, modern, easy to update, and (most importantly) cheap to run. Instead of grabbing a generic template, I decided to treat this like a mini production project. Here is how I built a high-performance DevOps portfolio using Next.js, Payload CMS, Neon, and Render.

Goal

I didn’t want a static site. I wanted a system that behaves like something you’d actually deploy in a real company.

  • A professional portfolio to showcase my work
  • A blog system where I can publish technical insights
  • A backend architecture that reflects real DevOps practices
  • A deployment setup that mirrors production environments

The Blueprint: Why This Tech Stack?

Every good DevOps project starts with architecture. I wanted a stack that separated my content from my frontend while keeping deployment dead simple.

  • Frontend: Next.js – It’s fast, handles SEO beautifully out of the box, and allows for static site generation. For a portfolio, speed is everything.
  • CMS: Payload CMS – I needed a headless Content Management System so I could easily add new freelance projects or blog posts without touching code. Payload is Node-based, incredibly flexible, and typescript-native.
  • Database: Neon – A serverless PostgreSQL database. It has a generous free tier, scales down to zero when nobody is visiting, and takes seconds to set up.
  • Hosting: Render – Docker-friendly, reliable, and a fantastic alternative to Heroku for hosting both the frontend and the CMS backend.

Setting Up the Database (Neon)

Before touching any code, I needed a place to store my data. I hopped over to Neon and spun up a serverless PostgreSQL instance. What I love about Neon from a DevOps perspective is the database branching feature. Just like Git, I can create a branch of my database for staging or testing without messing with my production data. Once the instance was live, I grabbed my connection string and moved on.

Building the Core with Payload CMS & Next.js

Payload CMS plays incredibly well with Next.js. In fact, you can run them together in a single repository. I initialized the project and configured Payload to use the Postgres database via the Neon connection string. Then, I defined my collections (the data structures):

  • Next.js handles the frontend (portfolio + blog UI)
  • Payload CMS manages backend logic and content APIs

This setup is simple, but it reflects real-world engineering principles: separation of concerns, scalability, and maintainability.

Deployment: Render

For deployment, I used Render to keep things simple and production-aligned. It allowed me to:

  • deploy both frontend and backend services
  • manage environments properly
  • connect services without unnecessary complexity
  • simulate real production deployment flows

The goal was not just to “host a website,” but to replicate a real deployment pipeline.

Real Challenges I Faced

Even with a clean stack, things weren’t straightforward. Some of the challenges included:

  • syncing frontend and backend environments correctly
  • managing database connections in production
  • handling Payload configuration in a deployed environment
  • debugging deployment issues between services
  • structuring APIs in a way that stays maintainable

These are the kinds of problems you only understand when you move from tutorials to real implementation.

Lessons Learned as a Freelancer

Building this site taught me a few valuable lessons:

  • Don't over-engineer early on: I initially thought about Dockerizing everything and throwing it onto a Kubernetes cluster. Glad I didn't. Render + Neon gave me the hands-off reliability I needed so I can focus on client work, not server maintenance.
  • Content accessibility matters: Having a real CMS (Payload) means I can update my portfolio from my phone if a client asks for a case study while I’m away from my laptop.
  • Show, don't just tell: Instead of just listing "AWS" or "Docker" on my resume, my new portfolio explicitly details how I used those tools to solve real business problems for my clients.

As a freelancer, this is the mindset clients actually care about.

Final Thoughts

Building this system was a shift in mindset. It’s no longer about “learning tools.” It’s about building systems that reflect real engineering standards. This portfolio represents the beginning of my freelance journey, not just as a developer, but as someone who understands how to design, deploy, and maintain real-world infrastructure.