Welcome to Dax Pro

Official documentation for Dax Pro — the premium .NET static site generator theme with Decap CMS. Everything you need to install, configure, and deploy a production-ready static site powered by pure C# and zero JavaScript runtime.

What Is Dax Pro?

Dax Pro is a premium, commercial theme package for the DAX static site generator — a pure C# build tool that compiles Markdown content into semantic HTML5 at build time. Dax Pro is not a CMS. It is not a JavaScript framework. It is not a runtime. It is a theme layer that sits on top of the DAX engine and gives you a production-ready enterprise website out of the box.

When you purchase Dax Pro, you receive:

  • Four enterprise-grade layouts — Home, Services, Blog, and Contact
  • A fully configured Decap CMS editorial interface — Git-based, no database
  • Complete deployment configuration for Netlify, Vercel, and Azure Static Web Apps
  • Auto-generated SEO artifacts — sitemap.xml, robots.txt, rss.xml, OpenGraph meta tags, JSON-LD structured data
  • One CSS file and one JavaScript file — no build step, no framework, no dependency tree
  • Lifetime updates and email support from the Dax Pro team
  • The underlying DAX engine is open source (MIT) and available at github.com/mesinkasir/dax. Dax Pro is the commercial theme layer built on top of it.

    Why Static, Why .NET, Why Now

    The modern web has a weight problem. A typical enterprise marketing site built on WordPress loads a PHP runtime, a MySQL database connection, a theme framework, and a dozen plugins before the first byte of HTML reaches the browser. A typical Blazor WASM application downloads 512 kilobytes of .NET runtime, boots a virtual machine in the browser, and hydrates the DOM — all before the reader can see a paragraph of text.

    Both approaches carry a permanent tax. WordPress pays it in security patches, database maintenance, and cache invalidation bugs. Blazor WASM pays it in bundle size, boot time, and search engine invisibility.

    Dax Pro rejects that tax entirely.

    The DAX engine compiles your content into static HTML at build time. A single C# file — Program.cs, roughly 800 lines — reads your Markdown, parses your YAML, applies your templates, and writes a folder of plain HTML files. There is no server runtime. There is no database. There is no client-side framework. The output is a directory of files that any static host or CDN can serve at the edge for fractions of a cent.

    The result is a website that:

  • Loads in under 50 milliseconds on a warm CDN
  • Scores 100/100 on every Lighthouse metric
  • Requires zero maintenance — no patches, no upgrades, no CVE alerts
  • Indexes perfectly in search engines because the HTML is real
  • Costs nearly nothing to host because it is just files
  • For content-heavy enterprise sites — marketing portals, documentation hubs, corporate blogs, service catalogs — this is the correct architecture. For interactive dashboards and authenticated applications, you should use Blazor or Razor Server. Use the right tool for the right job.

    What You Get in the Box

    When you download Dax Pro, you receive a complete project directory:

  • _data/ — site-wide configuration: metadata.yaml for SEO and identity, nav.yaml for navigation, footer.yaml for footer structure
  • content/ — your Markdown content: index.md for the homepage, about.md, contact.md, posts/ for blog articles, services/ for service pages, tags.md for taxonomy
  • templates/layouts/ — page layouts: base.dax as the HTML shell, home.dax, post.dax, service.dax, page.dax, contact.dax, tags.dax, tag.dax
  • templates/partials/ — reusable sections: hero, trust, solutions, performance, showcase, pricing, insights, contact form, SEO, navigation, footer
  • public/ — static assets: css/style.css, js/main.js, images/, admin/ for Decap CMS
  • config.yml — Decap CMS collection schema
  • netlify.toml — one-click Netlify deployment
  • README.md — quick-start guide
  • LICENSE — commercial license terms
  • Every file is documented. Every configuration value is explained. Nothing is hidden.

    How This Documentation Is Organized

    This documentation is written for developers and site owners who have purchased Dax Pro. It is not a general introduction to static site generation. It assumes you have:

  • A working .NET 9 SDK installed
  • A Git client
  • A code editor (VS Code recommended)
  • A Netlify, Vercel, or Azure account for deployment
  • Basic familiarity with YAML, Markdown, and command-line tools
  • The documentation follows the lifecycle of a Dax Pro project:

    1. Installation — get the code, install the SDK, run the build

    2. Configuration — edit metadata.yaml, nav.yaml, footer.yaml

    3. Content — write pages, blog posts, and service entries

    4. Templating — understand the layout system, partials, and variables

    5. Collections — use the automatic collection system for posts and services

    6. Decap CMS — configure the editorial interface

    7. Deployment — ship to Netlify, Vercel, or Azure

    Each chapter is self-contained. You can jump to the section you need. But if you are new to Dax Pro, read them in order — each chapter builds on the previous one.

    The Technical Contract

    Dax Pro makes specific promises about how it works. Understanding these promises saves you time debugging things that are not bugs.

    The engine is simple. Program.cs is a single file with no external dependencies beyond the .NET standard library. It reads _data/.yaml, parses content/.md, renders templates, and writes to site/. You can read the entire engine in an afternoon.

    Templates are logic-light. Dax Pro templates use three constructs: {% include file.dax %}, {% for item in list %}, and {% if condition %}. They are not a programming language. They do not have functions, variables, or complex expressions. This is intentional — templates that can do anything become unmaintainable. Dax Pro templates do one thing: render data into HTML.

    Data is flat by design. YAML nested deeper than two levels causes problems with simple parsers. Dax Pro keeps its YAML flat: top-level keys, one level of nesting, and lists of dictionaries where necessary. This makes the data easy to read, easy to edit, and easy to validate.

    Static means static. There is no server-side rendering, no API endpoints, no request handlers. A Dax Pro site is a directory of HTML files. If you need dynamic behavior, you use client-side JavaScript (like js/main.js for the mobile menu and form submission). If you need a database, you are using the wrong tool.

    CMS is optional. Dax Pro ships with Decap CMS pre-configured, but you do not have to use it. You can edit Markdown files directly in your editor of choice. Decap CMS is there for teams who need a visual interface, not because the theme requires it.

    What Dax Pro Is Not

    To avoid confusion later, here is what Dax Pro does not do:

  • It is not a runtime. There is no server to deploy, no container, no process. It is a build tool that produces files.
  • It is not a framework. You cannot write application logic in templates. You cannot create dynamic routes at request time.
  • It is not a CMS. Decap CMS is included, but it is a separate product. Dax Pro uses Decap CMS as an editorial layer; it does not replace it.
  • It is not free. Dax Pro is a commercial theme. The DAX engine is free (MIT); Dax Pro is licensed per purchase. See the License section for terms.
  • It is not a Blazor replacement. If you need interactive .NET applications with real-time state, use Blazor. Dax Pro is for content.
  • Getting Help

    If you get stuck, these are your support channels:

  • Email support — [email protected] — response within four business hours
  • Gumroad purchase page — creativitaz.gumroad.com/l/dax-pro — for license questions and updates
  • Fiverr consulting — fiverr.com/creativitas — for custom architecture work
  • DAX engine repository — github.com/mesinkasir/dax — for engine-level issues
Before emailing, check this documentation — the answer is almost certainly here. If it is not, email with a clear description of what you tried, what you expected, and what happened instead. Include the output of dotnet run -- build.

Ready to Begin?

The next chapter walks you through Installation — downloading the code, installing the .NET SDK, and running your first build. It takes about five minutes.

→ Continue to Installation