Digital Tools

How I Build and Publish This Website with Astro and Vercel

A practical look at how I built and publish my personal website using Astro, Markdown, GitHub, Decap CMS, and Vercel.

Cover illustration for “How I Build and Publish This Website with Astro and Vercel”

The architecture behind this website is deliberately simple: Astro for the site, Markdown for content, GitHub for version control, Decap CMS for publishing, and Vercel for hosting.

I built it this way because I wanted a personal website that was fast, easy to maintain, inexpensive, and not tied to a complicated dashboard or database.

The basic setup

The pages are generated by Astro during the build process and then delivered as static files through Vercel.

There is no database behind the public website and no server-side application required to display the articles.

Why I chose a static site

For a personal website, I don’t need a complicated infrastructure.

Speed: Static pages are lightweight and can be delivered efficiently through a CDN.

Security: Without a public database or server-side application, there are fewer components that need protection.

Portability: My articles remain as Markdown files in a Git repository rather than being locked inside a proprietary publishing system.

Cost: This setup can run at very low cost for a personal website.

Version history: Changes are tracked through Git, so I can see what changed and recover an earlier version when necessary.

For me, that balance is more useful than adding technology simply because it is available.

How I publish an article

I don’t normally edit the source code when publishing an article.

My publishing process is:

  1. I open

    /admin/

    and sign in.

  2. I write or edit the article.

  3. I add the title, description, category, date, cover image and other metadata.

  4. Decap CMS saves the content as Markdown in the GitHub repository.

  5. Vercel detects the change and starts a new build.

  6. After the build succeeds, the updated page is published.

This keeps the writing process separate from the development work.

The content remains plain Markdown with frontmatter, which also makes it easy to move or reuse later.

What each part does

Each tool has a relatively small job. That is intentional.

The checks that happen during publishing

A static website still needs quality control.

My build process checks important parts of the content and site structure before a new version goes live.

For example:

  • Content must follow the expected schema.
  • Required metadata must be present.
  • Dates and categories must use the correct format.
  • Canonical URLs and page metadata are generated consistently.
  • Search indexes, RSS and the sitemap are regenerated when content changes.
  • Image handling prevents simple path mistakes from becoming broken images.

The goal is simple: catch problems during the build instead of discovering them after publication.

What this setup does not have

The public website does not need:

  • User accounts or public logins
  • A content database
  • A traditional server-side CMS
  • A dynamic comments database
  • Real-time features

When something requires functionality that a static site does not provide, I use a small external service where necessary.

That keeps the core website simple.

If you want to build something similar

I would recommend building it in this order:

  1. Choose your domain and decide whether the canonical version uses

    www.

  2. Create the Git repository and start the Astro project.

  3. Define your content structure before publishing lots of articles.

  4. Connect the project to Vercel and get the basic deployment working.

  5. Add the CMS after the content model is stable.

  6. Create important pages such as Privacy Policy, Terms, Contact and Editorial Policy.

  7. Test the site properly before sharing it publicly.

  8. Publish a small collection of useful articles and improve the system as you go.

The important point is not to build everything at once.

Build the foundation first, then add only what you actually need.

How I maintain it

My maintenance routine is straightforward:

  • Draft and review articles before publishing.
  • Keep publication and updated dates accurate.
  • Check the build after major content or configuration changes.
  • Review privacy and legal pages when adding a new service.
  • Fix broken links, images and metadata when they are discovered.
  • Keep the technology stack as small as practical.

A personal website does not need constant technical work.

It needs a system that makes publishing and maintenance predictable.

Why I use this setup

There are many ways to build a website. WordPress, website builders and full-stack applications can all be good choices depending on the project.

For this website, I wanted something different.

I wanted my content to remain mine, my publishing process to stay simple, and the technical foundation to stay lightweight.

Astro, Markdown, GitHub, Decap CMS and Vercel give me that balance.

The result is not the most complicated website I could build.

It is simply a system that works for me.

Join the conversation

Was this article useful?

Views are counted only with analytics consent. Ratings, likes, and helpful votes are sent only when you choose them.

—article views
Rate this article
Loading ratings…

Your feedback helps improve future articles.

Community discussion

Comments 0

Comments are reviewed before they appear publicly. Be respectful and avoid sharing private information.

No approved comments yet. You can be the first to share a useful thought.

Add a comment

No account or login is needed. Your comment is emailed for moderation and is published only after approval in the CMS.

Sent securely through Web3Forms. Your email is used only to follow up if needed and is not included in the public comment.