Choosing technology for a blog and company website in 2026

23-08-2026Web DevelopmentAstro, Cloudflare Workers, AI Agents

Markdown, Astro, Workers and OpenTofu layers deployed to a global edge

In short: Astro + Cloudflare.

In 2026, a blog or a company website does not necessarily need a large CMS, an application server and a database. If speed, simplicity, low cost and good cooperation with AI agents matter, it is worth considering Astro, Cloudflare Workers and content stored directly in Git.

Astro as the foundation

Astro fits websites where most content is static: blogs, company websites, offers and landing pages.

A simple split is:

Markdown (.md) — articles and simple content,
MDX (.mdx) — content that needs individual components,
Astro (.astro) — offers, landing pages and more structured or dynamic views.

Do not use a more complex format when a simpler one is enough.

Astro builds the site into ready-to-serve HTML, CSS, JavaScript and assets. Most work can happen during the build instead of on every request.

This feels surprisingly close to how websites were built around 20 years ago. First there was HTML, then CSS and JavaScript, followed by PHP, Python, generic CMS platforms and increasingly complex frameworks.

AI agents are making that history turn back toward the roots. We can again work directly with simple documents while automation handles repetitive changes.

The same idea applies to HTML itself. A page does not need hundreds of classes and metadata attributes. Minimal CSS systems such as Pico CSS make semantic HTML practical again.

Markdown is also efficient for AI

Markdown is compact. Compared with verbose HTML or page-builder structures, it contains less repeated syntax for an AI agent to process.

That can mean:

fewer tokens,
faster agent work,
simpler modifications,
cleaner Git diffs,
easier automated content generation and updates.

Apply DRY where it reduces real repetition. Headers, CTAs, company information, offer sections and SEO data can live in shared components or data instead of being copied into dozens of files.

MD, MDX or Astro? The same case: an Offer page

A simple rule:

MD — the page is primarily content,
MDX — content needs a few components,
Astro — the page has its own layout, logic or richer UI.

Markdown: simple offer

---
title: "Infrastructure audit"
description: "Infrastructure audit and recommended changes."
---

# Infrastructure audit

We review architecture, security and costs.

## Scope

- infrastructure,
- security,
- costs,
- recommendations.

[Contact us](/contact/)

This is a good choice when the offer is mostly text. Less syntax also means fewer tokens when working with AI agents.

MDX: offer with a component

---
title: "Infrastructure audit"
---

import Price from "../components/Price.astro";

# Infrastructure audit

Analysis of infrastructure, security and costs.

<Price from="2500 PLN" />

[Ask about the audit](/contact/)

MDX makes sense when most of the page is still content but it needs a price block, gallery, CTA or another reusable component.

Astro: dedicated landing page

---
import Layout from "../layouts/Layout.astro";
import ContactForm from "../components/ContactForm.astro";

const title = "Infrastructure audit";
---

<Layout title={title}>
  <main>
    <h1>{title}</h1>
    <p>Analysis of infrastructure, security and costs.</p>

    <section>
      <h2>Scope</h2>
      <ul>
        <li>Infrastructure</li>
        <li>Security</li>
        <li>Costs</li>
      </ul>
    </section>

    <ContactForm />
  </main>
</Layout>

.astro is a good fit for an offer or landing page where page structure matters more than plain text.

The simplest format that meets the requirements is usually the best one.

Cloudflare Workers instead of traditional hosting

A built Astro site can be served through Cloudflare. Static assets can be delivered from the edge and application logic can be added with Workers only where it is needed.

The architecture matters more than a single benchmark: do as much work as possible at build time and cache aggressively instead of spending CPU on every visit.

Cloudflare provides, among other things:

CDN and cache,
DNS,
HTTPS,
redirects,
origin IP hiding behind the proxy,
Workers for edge logic.

This is particularly useful in a homelab. Public content can be served from the edge while the home infrastructure does not need to be directly exposed where it is unnecessary.

Infrastructure as Code with OpenTofu

Cloudflare configuration can be managed as code with OpenTofu.

DNS, redirects, rules and other infrastructure can then be reviewed and deployed similarly to application code.

A simple workflow becomes:

Markdown/Astro → Git → build → Cloudflare

An AI agent can work on content, application code and infrastructure configuration while every change remains reviewable in Git.

GitLab: repository and state

For a team, GitLab can serve both as the source repository and as a remote backend for OpenTofu state.

This allows application and infrastructure changes to follow the same review and deployment workflow.

For a small one-person project, local state with a reliable backup can be enough. Remote state becomes more valuable when multiple people or CI/CD modify the infrastructure.

GitLab as an OpenTofu state backend

With a team, state can be stored remotely in GitLab through the HTTP backend. The local .terraform/terraform.tfstate then contains backend configuration while the actual infrastructure state is remote.

After tofu init, the local file can contain data such as:

{
  "version": 3,
  "backend": {
    "type": "http",
    "config": {
      "address": "https://gitlab.com/api/v4/projects/project/terraform/state/cloudflare",
      "lock_address": "https://gitlab.com/api/v4/projects/project/terraform/state/cloudflare/lock",
      "unlock_address": "https://gitlab.com/api/v4/projects/project/terraform/state/cloudflare/lock",
      "username": "user"
    }
  }
}

.terraform/ is a working directory and should not be committed to Git. Credentials are better supplied through environment variables.

SEO, GEO and AI agents

With this stack, an AI agent works on simple text files rather than content hidden inside a CMS database and admin panel.

It can review and improve:

titles and descriptions,
heading structure,
internal links,
structured data,
canonical URLs,
sitemaps,
traditional SEO,
information structure useful for generative search and GEO.

This does not automatically guarantee good SEO or GEO. The advantage is a predictable structure that is easy to inspect, test and modify automatically.

Fast deployment

Without a traditional database and CMS panel, deployment is straightforward:

edit .md, .mdx or .astro,
commit,
build,
deploy to Cloudflare.

For small changes, an agent can prepare a complete commit covering content, metadata, internal links and required code changes.

Cost

For a small website, infrastructure cost stays close to zero. In practice, the main recurring costs may be the domain and AI tools.

Cloudflare has usage limits and paid plans, so not every configuration is free. A static website with effective caching, however, has modest infrastructure requirements.

AI costs can also be reduced through architecture:

Markdown instead of verbose HTML,
DRY instead of copied content,
small focused files,
shared components,
giving agents only the context they need.

Less code and less repetition means less maintenance, fewer tokens to process and fewer places for bugs to hide.

Summary

Astro + Markdown + Cloudflare + OpenTofu is a strong stack for a blog or company website in 2026 because it shifts complexity away from CMS and server maintenance toward simple source files, static output, caching and automation.

It is not the right solution for every project. A rich editorial workflow, complex permissions or highly dynamic functionality can justify additional layers.

For a developer or a small team, however, simplicity is a major advantage: content is code, infrastructure is code, and AI can work directly with both.