Coder Legion - Recent posts tagged schema

SEO Checklist for Indie Hackers: Sitemap, Schema, and llms.txt — the Three Files That Do the Talking

Tue, 27 Oct 2026 12:59:22 +0000

Most indie SEO advice is a list of things to write: more posts, better titles, target this keyword. That advice is not wrong, exactly. It is just the second half of the job, and it assumes the first half already happened — that search engines and AI assistants can actually find, understand, and trust your pages.

I run NitroIDE, a browser IDE on a static host with no server, no build step, and no plugin system. There is no SEO plugin to install. Everything machine-readable on the site is a file I wrote by hand or a script I maintain. That constraint turned out to be useful: it forced me to learn which three files actually matter, what each one is for, and how each one silently breaks.

Here is the checklist, in the order I would do it again.

1. The sitemap: prove every page exists

A sitemap is a list of your URLs, with a last-modified date for each, handed to search engines in a format they can crawl without guessing. It does not make a bad page rank. It makes a good page findable — especially on a site where new pages arrive one at a time and internal linking is thin.

The checklist for a sitemap:

Every page goes in, no exceptions. This is a rule I set for myself after redirect stubs got left out once: if a page exists and you want it found, it is in the sitemap. A sitemap that quietly omits pages is worse than no sitemap, because you stop checking.
Lastmod must be real. A lastmod date that never changes teaches crawlers to ignore your dates. Mine come from git history: the last commit that touched each page sets its lastmod. That is automated, so it cannot drift from reality the way a hand-edited date can.
Submit it, then check the report. A sitemap sitting in your repo root that nobody submitted is a wish, not a signal. Submit it in Search Console and read the coverage report: pages discovered, pages indexed, and — the useful part — the pages excluded and why.
Regenerate it when you publish. My publishing flow refreshes the sitemap with every new blog post. A sitemap that is stale on publish day is a sitemap that tells crawlers the new page does not exist yet.

The mistake that silently voids a sitemap is staleness, not syntax. Syntax errors show up loudly in the report. A sitemap that is valid but three months old just quietly stops describing your site.

2. Schema: tell machines what the page IS

If the sitemap says “these pages exist,” schema says “and here is what each one is.” JSON-LD is the format: a block of structured data in the page that names the thing — a software product, a blog post, a FAQ — in a vocabulary search engines already understand.

For an indie site, three types cover almost everything:

SoftwareApplication for the product itself: name, description, operating system, offers (free, in my case), and version. This is the one that lets a search result describe your tool as a tool, not as a generic webpage.
BlogPosting for articles: headline, author, date published, and date modified. The date-modified field matters more than people think — it is how a corrected, updated article signals that it is current rather than old.
FAQPage for pages that genuinely answer questions: a list of question-and-answer pairs, each complete in itself. Only use it where the page actually contains those answers visibly. Schema that describes content the page does not show is the fastest way to lose trust in all your schema.

Three rules for schema that I wish someone had given me earlier:

Validate before shipping, not after indexing. A structured-data testing tool will catch a missing comma or a wrong type in seconds. Waiting for Search Console to report it costs you a crawl cycle.
Match the visible page. Every fact in the schema should be findable by a human reading the page. If the schema claims a price, a rating, or a feature the page never mentions, that is not optimization — it is a mismatch waiting to be flagged.
Keep it boring. Schema is not the place for creativity. Use the standard types, the standard property names, and nothing clever. The whole point is that a machine on the other end already knows what these words mean.

The mistake that silently voids schema is the same as the sitemap's, in a different costume: schema that describes last month's page. When you change a price, a version, or a headline, the schema changes in the same commit, or it becomes a lie told in a format machines trust.

3. llms.txt: the file for readers that are not browsers

Sitemaps and schema are for search engines. llms.txt is for a newer reader: AI assistants that want to understand your site without crawling every page and reconstructing the picture from fragments. It is a short, plain-text file at your site root that says what the site is, what its important pages are, and where to find them.

I added one recently, and it taught me something the other two files did not: a summary file is a second source of truth. A reader on Peerlist put it better than I did — llms.txt is like a contract summary versus the document itself. Useful, but only while it matches the document. The moment the site changes and the summary does not, the summary is not just stale, it is actively misleading the exact readers you wrote it for.

So the checklist for llms.txt is short and strict:

Keep it short. It is a map, not a mirror. Link to the real pages; do not paste their content in.
Update it with the site. When a new section ships or an old page goes away, the file changes in the same round of work. Treat it like the sitemap: maintained by the publishing flow, not by memory.
Say what the site is in one paragraph. The first lines are the whole pitch to a reader that will never see your homepage design. If those lines are vague, the rest of the file does not rescue them.

The mistake that silently voids llms.txt is neglect. Unlike a broken sitemap, which Search Console reports, a stale llms.txt produces no error. It just keeps answering questions about a site that no longer exists.

The whole checklist, on one screen

Sitemap: every page in, lastmod from a real source, submitted, refreshed on publish.
Schema: SoftwareApplication for the product, BlogPosting for articles, FAQPage only where the page really answers questions — validated, matching the visible page, using standard types.
llms.txt: short, linked (not pasted), updated with the site, with a one-paragraph description that actually says what the site is.
After shipping, verify all three: Search Console coverage for the sitemap, a structured-data test for the schema, and a plain read of llms.txt to check it still describes the site you have.

None of this replaces writing something worth finding. But it is the difference between a good page that search engines and AI assistants can describe accurately, and a good page they have to guess at. Indie hackers do not have a marketing team to do the guessing for them. These three files are the team.

Google killed FAQ rich results in May 2026. Stop selling FAQ schema as an AI ranking trick.

Tue, 06 Oct 2026 05:21:08 +0000

On 7 May 2026, FAQ rich results disappeared from Google Search. Not for some sites. For all of them.

Yet checklists, plugins and "AEO audits" still promise that FAQPage markup gets you into the answer box, or makes ChatGPT quote you. I wrote some of those lines myself, a year ago. Here is what is true now.

The timeline

Date	What happened
Aug 2023	FAQ rich results limited to well-known government and health sites
7 May 2026	FAQ rich results gone from Google Search for everyone
Jun 2026	FAQ report, search appearance and Rich Results Test support removed from Search Console
Aug 2026	FAQ support removed from the Search Console API

John Mueller's comment was blunt: for most sites nothing changes, because the markup was already ignored.

What FAQPage still does

It is valid schema.org. Leaving it on a page does no harm, Google says.
Other parsers can read it. Nobody publishes how much they use it.
Visible Q&A is still useful. Real answers to real questions are easy for people and machines to quote — with or without markup.

What it no longer does

No FAQ result in Google.
No FAQ testing in Search Console.
No proven effect on AI citations. I looked. There is no published evidence that FAQPage markup makes ChatGPT, Perplexity or Google's AI features cite a page.

What to do on a store

Keep FAQPage where the Q&A is visible and real: shipping, returns, sizes.
Remove it where it was added only for Google — hidden FAQs, filler questions.
Spend the time on schema that still matters: Product with offers.availability, shipping, return policy, and a consistent @id graph.
Fix old promises in your own docs.

In my own audit tool, the FAQ check now has the lowest weight of all 20 signals. A missing FAQPage can never fail a store on critical severity.

Full article with sources: angeo.dev/faqpage-schema-after-2026/

Do you still see agencies selling FAQ schema as an AI visibility fix?

What Is Structured Data? A Plain-Language Guide to Schema Markup

Mon, 05 Oct 2026 12:04:36 +0000

What Is Structured Data? A Plain-Language Guide to Schema Markup

If you have spent any time reading about SEO, you have probably run into the term "structured data" or "schema markup" and quietly moved on, assuming it was something only developers needed to worry about.

It is simpler than it sounds, and understanding the basics helps you have better conversations with whoever builds or maintains your site, even if you never write a line of it yourself.

This guide explains what structured data actually is, what it can and cannot do for your SEO, and how it gets added to a real website.

What Structured Data Actually Is

Structured data is a standardized way of labeling the content on your page so search engines can understand what that content means, not just what it says.

A human reading your page can tell, just by looking, that "4.8 stars, 212 reviews" refers to a product rating. A search engine crawling raw HTML cannot make that same leap on its own. Structured data closes that gap by explicitly tagging the information: this is a rating, this is the review count, this is the price, this is the business address.

The vocabulary most sites use for this comes from Schema.org, a shared standard maintained jointly by Google, Microsoft, Yahoo, and Yandex specifically so that search engines agree on what the same markup means.

Why It Matters Beyond Just "Being Thorough"

Google's own documentation describes structured data as a way to help their systems understand your page content and, where eligible, display it as a rich result in search listings.

Rich results are the enhanced listings you have scrolled past dozens of times without necessarily noticing them as a separate category: star ratings under a product link, a recipe with a photo and cook time, an FAQ that expands directly in the search results, a job posting with salary and location shown upfront.

These enhanced listings take up more visual space and tend to draw the eye more than a plain blue link. For a business, that can mean a meaningful difference in click-through rate for the same ranking position, because your result simply looks more informative than the ones around it.

What Structured Data Does Not Do

This is the part most explanations skip, and it matters because expecting the wrong outcome leads to disappointment and, sometimes, to shady "SEO fixes" that promise more than schema markup can deliver.

Structured data does not directly improve your ranking position. Google has been consistent on this point: adding schema does not push you from position 8 to position 2. What it can do is make an existing listing more eligible for a rich result, and make that listing more appealing once it is shown.

Structured data also does not guarantee a rich result will appear, even when it is implemented correctly. Eligibility depends on your markup being valid, but Google's systems still decide whether, when, and how to display any enhanced result. Treat it as something that improves your odds and your presentation, not something that purchases a specific outcome.

Common Types of Structured Data Worth Knowing

You do not need to learn the entire Schema.org vocabulary. A small handful of types cover most small business and content sites.

Article marks up a blog post or news piece, with fields like headline, author, and publish date. If you are working through a broader technical SEO setup, this is usually one of the easier wins; see our Next.js SEO checklist for where it fits alongside metadata and sitemaps.

Product covers items for sale, including price, availability, and rating, and is what powers the star ratings you see under shopping-related results.

FAQPage marks up a genuine question-and-answer section on your page, and is part of why some pages show an expandable FAQ directly in search results.

LocalBusiness covers address, hours, and phone number for a physical or local-service business, helping search engines connect your page to local search and map results.

Review marks up individual reviews or testimonials, often paired with Product or LocalBusiness markup.

BreadcrumbList describes your site's navigation hierarchy, which can shape how your URL path displays in search results.

How Structured Data Actually Gets Added

In practice, structured data is almost always added using a format called JSON-LD, a small block of code placed in the page's HTML that describes the page's content in a structured, machine-readable way.

It looks something like this, simplified for a blog post:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "What Is Structured Data? A Plain-Language Guide to Schema Markup",
  "datePublished": "2026-10-02",
  "author": {
    "@type": "Person",
    "name": "Anas"
  }
}

This block does not change anything visible on the page itself. It sits quietly in the code, readable by search engines but invisible to a regular site visitor, describing the content that is already there.

Most modern website builders and content management systems can generate this automatically for common page types, and most developers can add it directly into a site's templates so every new post or product page gets it without manual repetition.

How to Check If Your Structured Data Is Actually Working

Adding structured data and having it work correctly are two different things, since even small syntax errors can make an entire block invalid.

Google's Rich Results Test lets you paste in a URL or a block of code and see exactly what Google's systems detect, along with any errors or warnings. This is the most reliable way to confirm your markup is valid rather than assuming it is working because you can see it in the page source.

If you have already set up Google Search Console for your site, its enhancement reports will also flag structured data issues across your site over time, which is useful for catching problems on pages you are not actively checking one by one.

Frequently Asked Questions

Does structured data improve my Google ranking directly?

No. It can make your listing more likely to show as a rich result and more appealing once it appears, but it is not a ranking factor on its own.

Do I need a developer to add structured data?

Not always. Many website builders and CMS platforms generate common types automatically. Custom or highly specific markup usually does benefit from a developer's involvement, particularly to keep it valid as the page content changes.

Will adding structured data guarantee my page gets a rich result?

No. It makes your page eligible, but Google's systems decide independently whether, when, and how to display any enhanced result.

What happens if my structured data has errors?

Depending on the severity, Google may ignore just the broken portion or the entire block. This is why testing your markup after adding it, rather than assuming it works, is a necessary step.

Conclusion

Structured data is not a magic ranking lever, and treating it that way sets you up for disappointment. What it actually does is help search engines understand your content more precisely and gives your listings a better shot at standing out visually when they do appear in results.

For most small business sites, starting with Article, FAQPage, and LocalBusiness markup where relevant covers the majority of practical benefit without requiring a deep dive into the full Schema.org vocabulary.

If you want a second pair of eyes on your site's technical SEO setup, including structured data, get in touch.

Anas, full-stack Next.js developer building SaaS products and premium templates.

Helm Values JSON Schema: Validate Your values.yaml Before It Breaks Production

Mon, 27 Apr 2026 09:13:42 +0000

Helm is the de facto package manager for Kubernetes, and values.yaml is its primary interface for configuration. Yet for years, that interface has been completely unvalidated by default — a free-form YAML file where any key can be anything, where typos silently pass through, and where misconfigured deployments only reveal themselves when pods fail to start in production. The values.schema.json file changes that equation entirely. This article explains why schema validation matters, how to implement it properly, and how to integrate it into a modern CI/CD pipeline.

The Problem: Silent Failures in Production

Consider a platform team managing dozens of Helm releases across multiple clusters. A developer submits a values override file with replicaCount: "3" instead of replicaCount: 3 — a string where an integer is expected. Or they set image.pullPolicy: Allways with a typo. Or they omit a required secret reference that the application needs to boot. In all three cases, Helm without schema validation will happily render the templates, produce Kubernetes manifests, and apply them to the cluster. The failure surfaces later — sometimes much later — as a CrashLoopBackOff, an ImagePullBackOff, or a subtle runtime error that takes hours to debug.

This is not a hypothetical scenario. It is the daily reality for teams operating at scale without values validation. The root cause is architectural: Helm templates use Go’s text/template engine, which is weakly typed and permissive by design. A template that does {{ .Values.replicaCount }} will render whether the value is an integer, a string, or even a boolean. The resulting Kubernetes manifest may be invalid, but that error only surfaces when the Kubernetes API server rejects it — or worse, accepts it but interprets it differently than intended.

The consequences compound at scale. When a chart is used by multiple teams, the lack of a formal contract for acceptable values means every consumer has to read through template files and comments to understand what inputs are valid. There is no machine-readable specification. There is no IDE support. There is no guardrail. The only documentation is whatever the chart author happened to write in comments inside values.yaml — and comments do not stop a CI pipeline from shipping a broken deployment.

What Is values.schema.json

Since Helm 3.0.0, released in November 2019, Helm supports an optional values.schema.json file at the root of a chart directory — the same level as Chart.yaml and values.yaml. This file is a JSON Schema draft-07 document that formally describes the structure, types, constraints, and required fields for the chart’s values.

When this file is present, Helm automatically validates the merged values (defaults from values.yaml merged with any user-supplied overrides) against the schema at multiple points: during helm install, helm upgrade, helm template, and helm lint. If validation fails, Helm refuses to proceed and prints a human-readable error message identifying exactly which value failed and why. This transforms a class of runtime failures into build-time failures — the correct direction for any production system.

The choice of JSON Schema draft-07 specifically is worth noting. Draft-07 is widely supported by tooling, including the Red Hat YAML extension for VS Code, JetBrains IDEs, and most JSON Schema validators. It introduced the if/then/else conditional keywords that are particularly useful for Helm charts. More recent drafts (2019-09, 2020-12) offer additional features but have less universal tooling support, making draft-07 the pragmatic choice for chart authors today.

Chart Directory Structure

my-app/
├── Chart.yaml
├── values.yaml
├── values.schema.json      ← lives here
├── charts/
└── templates/
    ├── deployment.yaml
    ├── service.yaml
    ├── ingress.yaml
    └── _helpers.tpl

The schema file is included when a chart is packaged with helm package and distributed through chart repositories. Consumers of the chart get schema validation automatically without any additional configuration — the guardrails ship with the chart itself.

How Helm Uses the Schema

Helm’s validation behavior is straightforward but has some nuances worth understanding. When Helm processes a release, it first merges all value sources in order of increasing precedence: chart defaults (values.yaml), parent chart values, -f value files, and finally --set flags. The merged result is then validated against the schema as a single operation.

This means the schema validates the effective values, not each source in isolation. A required field that has a default in values.yaml will pass validation even when not specified by the user, because the merged result includes the default. This is the correct behavior — it validates what will actually be used during rendering.

The validation happens before template rendering. If schema validation fails, Helm exits with a non-zero status code and prints all validation errors. The error output is structured and actionable:

$ helm install my-release ./my-app --set replicaCount=abc

Error: values don't meet the specifications of the schema(s) in the following chart(s):
my-app:
- replicaCount: Invalid type. Expected: integer, given: string

For helm lint, which is typically used in CI pipelines without installing to a cluster, schema validation also runs. This makes helm lint a powerful pre-deployment gate when schema files are present.

IDE Benefits: Autocompletion and Inline Validation

Beyond Helm’s own validation, values.schema.json unlocks IDE support that significantly improves the developer experience when working with values files. The Red Hat YAML extension for VS Code can reference a JSON Schema file to provide autocompletion, type checking, and inline error highlighting for YAML files.

To enable this, add a yaml.schemas configuration to your VS Code workspace settings or the user settings file:

// .vscode/settings.json
{
  "yaml.schemas": {
    "./my-app/values.schema.json": "./my-app/values.yaml"
  }
}

With this configuration, editing values.yaml in VS Code will show autocompletion for defined keys, inline errors for type mismatches, and hover documentation pulled from the description fields in your schema. For platform teams maintaining internal Helm charts, this transforms the chart into a self-documenting, IDE-aware configuration interface — without any additional tooling investment.

JetBrains IDEs (IntelliJ IDEA, GoLand, etc.) support JSON Schema associations through the Languages & Frameworks > Schemas and DTDs > JSON Schema Mappings settings panel, providing equivalent functionality for teams using those tools.

Building the Schema: A Practical Guide

Let’s build a complete, realistic example. Start with a typical values.yaml for a web application chart:

# values.yaml
replicaCount: 2

image:
  repository: myorg/my-app
  tag: "1.0.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: false
  hostname: ""
  tls: false

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 80

config:
  logLevel: info
  databaseUrl: ""

nodeSelector: {}
tolerations: []
affinity: {}

Now the full values.schema.json that validates this structure:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "my-app Helm Chart Values",
  "description": "Configuration values for the my-app Helm chart",
  "type": "object",
  "additionalProperties": false,
  "required": ["image", "service"],
  "$defs": {
    "resourceQuantity": {
      "type": "string",
      "pattern": "^[0-9]+(\\.[0-9]+)?(m|Ki|Mi|Gi|Ti|Pi|Ei|k|M|G|T|P|E)?$",
      "description": "A Kubernetes resource quantity (e.g. 100m, 128Mi, 1Gi)"
    }
  },
  "properties": {
    "replicaCount": {
      "type": "integer",
      "minimum": 0,
      "maximum": 50,
      "default": 2,
      "description": "Number of pod replicas. Set to 0 to scale down."
    },
    "image": {
      "type": "object",
      "additionalProperties": false,
      "required": ["repository", "tag"],
      "description": "Container image configuration",
      "properties": {
        "repository": {
          "type": "string",
          "minLength": 1,
          "description": "Container image repository"
        },
        "tag": {
          "type": "string",
          "pattern": "^[a-zA-Z0-9._-]+$",
          "minLength": 1,
          "description": "Image tag. Avoid using 'latest' in production."
        },
        "pullPolicy": {
          "type": "string",
          "enum": ["Always", "IfNotPresent", "Never"],
          "default": "IfNotPresent",
          "description": "Kubernetes imagePullPolicy"
        }
      }
    },
    "service": {
      "type": "object",
      "additionalProperties": false,
      "required": ["type", "port"],
      "properties": {
        "type": {
          "type": "string",
          "enum": ["ClusterIP", "NodePort", "LoadBalancer", "ExternalName"],
          "description": "Kubernetes Service type"
        },
        "port": {
          "type": "integer",
          "minimum": 1,
          "maximum": 65535,
          "description": "Service port"
        }
      }
    },
    "ingress": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "enabled": {
          "type": "boolean",
          "default": false
        },
        "hostname": {
          "type": "string",
          "description": "Ingress hostname. Required when ingress.enabled is true."
        },
        "tls": {
          "type": "boolean",
          "default": false,
          "description": "Enable TLS for the ingress"
        }
      },
      "if": {
        "properties": {
          "enabled": { "const": true }
        },
        "required": ["enabled"]
      },
      "then": {
        "required": ["hostname"],
        "properties": {
          "hostname": {
            "minLength": 1,
            "pattern": "^[a-zA-Z0-9]([a-zA-Z0-9\\-\\.]+)?[a-zA-Z0-9]$"
          }
        }
      }
    },
    "resources": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "requests": {
          "type": "object",
          "additionalProperties": false,
          "properties": {
            "cpu": { "$ref": "#/$defs/resourceQuantity" },
            "memory": { "$ref": "#/$defs/resourceQuantity" }
          }
        },
        "limits": {
          "type": "object",
          "additionalProperties": false,
          "properties": {
            "cpu": { "$ref": "#/$defs/resourceQuantity" },
            "memory": { "$ref": "#/$defs/resourceQuantity" }
          }
        }
      }
    },
    "autoscaling": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "enabled": {
          "type": "boolean",
          "default": false
        },
        "minReplicas": {
          "type": "integer",
          "minimum": 1
        },
        "maxReplicas": {
          "type": "integer",
          "minimum": 1,
          "maximum": 100
        },
        "targetCPUUtilizationPercentage": {
          "type": "integer",
          "minimum": 1,
          "maximum": 100
        }
      },
      "if": {
        "properties": {
          "enabled": { "const": true }
        },
        "required": ["enabled"]
      },
      "then": {
        "required": ["minReplicas", "maxReplicas"]
      }
    },
    "config": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "logLevel": {
          "type": "string",
          "enum": ["debug", "info", "warn", "error"],
          "default": "info",
          "description": "Application log level"
        },
        "databaseUrl": {
          "type": "string",
          "description": "Database connection URL"
        }
      }
    },
    "nodeSelector": {
      "type": "object",
      "description": "Node selector labels for pod scheduling"
    },
    "tolerations": {
      "type": "array",
      "description": "Pod tolerations"
    },
    "affinity": {
      "type": "object",
      "description": "Pod affinity rules"
    }
  }
}

Key Schema Patterns Explained

additionalProperties: false

This is arguably the most important pattern in a Helm schema. Without it, unknown keys pass validation silently — which defeats much of the purpose. With "additionalProperties": false, any key not listed in properties causes a validation error. This catches typos like repicaCount instead of replicaCount, which would otherwise silently use the default value and leave the developer wondering why their override had no effect.

Apply it at every nested object level, not just the root. A typo inside image: or resources: is just as dangerous as one at the top level.

$defs for Reusable Definitions

The $defs keyword (called definitions in earlier draft versions, though draft-07 supports both) provides a namespace for reusable schema fragments. In the example above, resourceQuantity is defined once and referenced via $ref in both requests and limits. This avoids duplication and ensures consistent validation logic across related fields.

For larger charts, $defs becomes essential. Common patterns include reusable schemas for image configurations, resource requirements, probe configurations, and environment variable maps.

Conditional Validation with if/then/else

The if/then/else construct in JSON Schema draft-07 is particularly powerful for Helm charts, where many values are conditional on a feature toggle. The ingress example above demonstrates this: when ingress.enabled is true, the hostname field becomes required and must match a valid hostname pattern. When ingress is disabled, the hostname can be empty or omitted entirely.

This pattern can be extended for more complex scenarios. For example, enforcing that when autoscaling.enabled is true, the standalone replicaCount should not be set (since the HPA controls replica count):

{
  "if": {
    "properties": {
      "autoscaling": {
        "properties": {
          "enabled": { "const": true }
        },
        "required": ["enabled"]
      }
    }
  },
  "then": {
    "properties": {
      "replicaCount": {
        "description": "replicaCount is ignored when autoscaling is enabled"
      }
    }
  }
}

Pattern Validation for Image Tags

The image tag field is a common source of production issues. Teams accidentally deploy with latest, which is non-deterministic and makes rollbacks unreliable. A pattern constraint can enforce semantic versioning or at least ban the latest tag in production charts:

"tag": {
  "type": "string",
  "not": {
    "enum": ["latest", ""]
  },
  "pattern": "^[0-9]+\\.[0-9]+\\.[0-9]+",
  "description": "Semantic version tag required. 'latest' is not permitted."
}

This enforces that image tags start with a semantic version number, immediately rejecting latest, empty strings, or arbitrary branch names that would produce non-reproducible deployments.

Enum for Controlled Vocabularies

Fields with a fixed set of valid values — Kubernetes service types, image pull policies, log levels — should use enum. This is more precise than a pattern and produces clearer error messages. It also enables IDE autocompletion to show exactly the valid options as a pick-list, rather than requiring the developer to remember or look up acceptable values.

CI/CD Integration

GitHub Actions

The most direct integration point is helm lint, which runs schema validation as part of its checks. A minimal GitHub Actions workflow that validates a chart on every pull request looks like this:

# .github/workflows/helm-lint.yaml
name: Helm Lint

on:
  pull_request:
    paths:
      - 'charts/**'

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Helm
        uses: azure/setup-helm@v4
        with:
          version: '3.14.0'

      - name: Lint chart with default values
        run: helm lint charts/my-app

      - name: Lint chart with staging values
        run: helm lint charts/my-app -f charts/my-app/ci/staging-values.yaml

      - name: Lint chart with production values
        run: helm lint charts/my-app -f charts/my-app/ci/production-values.yaml

      - name: Validate template rendering
        run: |
          helm template my-app charts/my-app \
            -f charts/my-app/ci/production-values.yaml \
            --debug > /dev/null

The ci/ directory convention (values files specifically for CI testing) is a pattern from the chart-testing tool and works well for validating multiple realistic value combinations, not just the defaults.

For teams using th

Implementing WebMCP on a Recruitment Website

Tue, 21 Apr 2026 09:58:19 +0000

Thinking about what, exactly, the future of a website “looks” like in the agentic era is a challenging proposition. It might be that in most cases, our future viewers/readers/customers can do everything, from their chatbot of preference while never visiting your site.

WebMCP is a part of this puzzle. The protocol directs an agent to stop guessing what a button does, and starts calling tools with typed inputs with a fundamentally simple tool registration protocol.

So, what’s WebMCP? WebMCP is “an emerging W3C standard developed by Google and Microsoft that acts as a browser API to turn websites into interactive tools for AI agents”.

This is the future and I think it’s very exciting. For fun, I added WebMCP support to YubHub , (my recruitment site).

Today, I’m going to talk about what I learned building, the design choices we made that worked, an agent trace that caught a hallucination in a production system (fixed), and why (in my opinion!) a recruitment site turned out to be an unusually good fit for this protocol.

YubHub in Chrome 146 with the Model Context Tool Inspector open.

Why a Recruitment Site?

Because websites new and old are going to have to change rather quickly (and, I really enjoy starting online business from scratch – the test of a true martech marketer!).

Most of the WebMCP explainers I read while researching this use a checkout flow, a to-do list, or a colour picker. Toys. They work for illustrating the API surface (what can this new thing do?), but without implmenting and playing with teh protocol yourself I fear the penny simply does not drop.

The real value with WebMCP emerges when an agent needs to reason about a lot of structured data that’s already behind a nice URL structure – and recruitment sites are built around exactly that shape: job details, salary ranges, skills required or employment locations.

YubHub already served clean data at predictable URLs (/jobs/skill/figma, /jobs/at/anthropic) and emits schema.org JobPosting markup. What it didn’t have was a “contract”. Any agent browsing the site could see the HTML and JSON-LD I’m sure, but getting an agent to browse your website for an answer via Chrome is just the craziest waste of time when ideas as fundamental as an API have been around for decades.

WebMCP fixes that by publishing the interface explicitly, with typed inputs and structured responses. Prompt in > “find me an X for a Y in Z”. So, for a site whose whole job is “be discoverable”, WebMCP is a big deal.

The basic flow. The page registers tools on navigator.modelContext, the agent discovers and invokes them, the page replies with structured data. No screen-scraping in between.

What’s WebMCP?

WebMCP is a proposed web standard, co-authored by engineers at Google and Microsoft under the W3C Web Machine Learning community group, that lets a site expose a set of callable tools to an AI agent running in the browser. There are two APIs: imperative (navigator.modelContext.registerTool() called from JavaScript), and declarative.

Think of it as a contract the site publishes to any agent that lands on it. Instead of the agent guessing that a div with class="btn-primary" means “checkout”, the page says: here’s a checkout tool, here’s what it needs, here’s what you’ll get back.

That’s a welcome leap from screen-scraping and MCP based browser control. The Chrome DevTools MCP quickstart benchmarked a simple “set counter to 42” task at 3,801 tokens using screenshots and 433 tokens using WebMCP. That’s an 89% reduction in token use!

The current spec lives on the W3C community group site (webmachinelearning.github.io/webmcp), with Chrome’s early-preview announcement and detailed posts on developer.chrome.com/blog/webmcp-epp. It ships behind a flag in Chrome Canary 146. Google Chrome Labs maintain a reference extension – the Model Context Tool Inspector – that lists the tools any page has registered and lets you call them manually. If you’re planning to build anything with this, you’ll want both installed.

How WebMCP Differs From MCP

The names don’t help much, do they! Model Context Protocol (MCP) is server-side – you deploy an MCP server that an agent connects to, it runs in its own process, exposes tools to your AI assistant over JSON-RPC. We have a growing library of our own MCP connectors like my favourites Gemini MCP and Houtini-LM.

WebMCP is the browser-side sibling. Your tool code runs in the page’s JavaScript context, so it has the user’s cookies, their session, their permissions – everything the user already has access to. There’s no deployment, no auth bridge, no server to pay for. Well, mostly – you still have to maintain the page, obviously, but there’s nothing extra. If your site already authenticates the user, your WebMCP tools inherit that authentication for free.

The practical consequence: MCP is the right fit for agents that need third-party data (GitHub, Gmail, a database). WebMCP is the right fit for agents that need to interact with a specific site the user has requested.

Getting Set Up

If you have Chrome Canary 146 or higher, you are already setup. The stable, Beta, and Dev channels of Chrome do not ship with the WebMCP flag – so you have to enable it:

Open a new tab to chrome://flags/#enable-webmcp-testing and set “WebMCP for testing” to Enabled. Click Relaunch.

Enable WebMCP for testing

Third, install the Model Context Tool Inspector extension from the Chrome Web Store. This is currently the only way to test anything before you’ve wired an agent in. It lists every tool the current page has registered, shows you their JSON schemas, and lets you execute them manually with whatever input you want. The extension requires a Gemini API key as the extension uses Gemini as a natural-language test harness, which is useful for checking whether your tool descriptions are clear enough for a real LLM to pick the right tool. This is much like tool context set in tool descriptions in the MCP protocol.

The WebMCP Inspector extension.

To verify the whole thing is working, open DevTools and run console.log(navigator.modelContext). If you see an object come back rather than undefined, you’re in business. If it’s undefined, either your flag isn’t set or you’re on the wrong Chrome channel.

Setting Up the Imperative API

Here’s the minimum viable tool registration from YubHub’s live scaffold:

if (!navigator.modelContext) return;

var pageController = new AbortController();
addEventListener('pagehide', () => pageController.abort(), { once: true });

navigator.modelContext.registerTool({
  name: 'yubhub_fetch_job',
  description: 'Fetch a single YubHub job as clean markdown (company, location, salary, work arrangement, full description, apply URL, skills). More token-efficient than the HTML page.',
  inputSchema: {
    type: 'object',
    properties: {
      id: { type: 'string', pattern: '^job_[a-z0-9_-]+$' },
    },
    required: ['id'],
  },
  execute: async (params) => {
    const r = await fetch('/jobs/' + params.id + '.md',
      { headers: { Accept: 'text/markdown' } });
    return { id: params.id, markdown: await r.text() };
  },
}, { signal: pageController.signal });

There are 4 things to look at here – firstly, the feature-detection guard – navigator.modelContext only exists in Chrome 146 with the flag on, so every public-facing scaffold needs to short-circuit gracefully elsewhere or you’ll throw on every other browser your users visit from.

The pattern constraint on id – the spec treats JSON Schema loosely in the browser, so validating in code catches the cases the schema doesn’t. And the return value is a structured object, not a string – the agent reads it as data rather than trying to parse text/html.

The Inspector showing the tool’s schema (green box) and the agent’s prompt (red box). You can drive this entirely by hand during development, which is the fastest way to catch bad tool descriptions.

The Declarative API Is Free Engineering

I think this is the cleverest part of the WebMCP spec. If you’ve got an HTML form – and of course, you do, you can annotate it and get a tool registration for free.

YubHub’s nav already had a GET form submitting to /jobs/search. All I did was add three attributes:

<form action="/jobs/search" method="GET"
      toolname="yubhub_search"
      tooldescription="Search YubHub's enriched job board by free-text query - title, company, or keyword. Submits a GET to /jobs/search and renders the results page."
      toolautosubmit>
  <input type="search" name="q"
         toolparamdescription="Job title, company name, or any keyword (2-100 chars)"
         minlength="2" maxlength="100" />
</form>

The browser reads the form, builds a JSON Schema from the input fields, and registers it as a tool. When an agent calls it with {q: "python"}, the browser focuses the form, populates the input, and – because of toolautosubmit – submits it automatically. Zero JavaScript. Your form already works for humans; now it works for agents.

One thing worth flagging: toolautosubmit is only really safe on read-only operations. Search queries, availability lookups, status checks – fine, let the agent submit. Anything that creates, modifies, or deletes data should leave the flag off, so the human has to click Submit after the agent fills the form.

And that, I reckon, is how WebMCP adoption will probably start to emerge – by adding it to their internal site search forms and results pages. But I hope to see people agreeing that this idea undersells what WebMCP can do in the longer term.

Context-Scoped Tool Registration

I’ve got a tool called yubhub_current_job. It takes no arguments, and it just returns the current job’s markdown. Obviously, that only makes sense on my job listing pages, so anywhere else on the site it would be meaningless (worse, it’d be confusing). The scaffold pattern-matches the URL and registers conditionally:

const jobMatch = location.pathname.match(/^\/jobs\/(job_[a-z0-9_-]+)$/i);
if (jobMatch) {
  const currentJobId = jobMatch[1];
  navigator.modelContext.registerTool({
    name: 'yubhub_current_job',
    description: 'Return clean markdown for the job the user is currently viewing ('
      + currentJobId + '). Zero-arg shortcut.',
    inputSchema: { type: 'object', properties: {} },
    execute: async () => {
      const r = await fetch('/jobs/' + currentJobId + '.md');
      return { id: currentJobId, markdown: await r.text() };
    },
  }, { signal: pageController.signal });
}

The AbortController ties it to the page lifecycle – when the user navigates away, pagehide fires, the controller aborts, and all tools registered with its signal drop off the agent’s radar. Importantly this leaves no leftover closures holding references to the previous page’s state.

Same site, three pages, three different tool menus. The agent sees only the tools that make contextual sense.

There are two kinds of tools you can give an agent, and they create completely different user experiences.

Navigation tools change the URL on the user’s behalf. They’re the right call when the user actually wants to end up somewhere else – looking at a specific job, browsing a facet, running a search. So the agent calls yubhub_browse_jobs({type: 'skill', slug: 'figma'}), the tab navigates, the user sees the archive page. The return value is basically a receipt (“I took you here, here’s what’s on the page”).

The real power, IMO, is this: Data-retrieval tools return parsed data and leave the URL alone. The agent calls them to reason, compare, filter, summarise – and the user stays on whatever page they were already on, quite unaware that the agent just read a hundred jobs to answer a question. yubhub_fetch_facet returns up to 100 schema.org JobPosting entries; yubhub_shortlist filters them by salary floor, remote status, title keyword, and hands back a ranked list.

Data-retrieval is what I’m bullish on – it’s a midbendingly powerful solution to the current state of play with AI based webcrawl / actions for users and so on.

_yubhub_shortlist returning a ranked list of product manager roles._

Only shipping navigation tools is the mistake I’d warn you off. It just makes the agent a fancy URL-rewriter – it can answer “take me to X”, but it can’t answer “summarise the options and recommend one” without hauling the whole user along.

What WebMCP Can’t Do (Yet)

A browsing context is required. There’s no headless mode – if a tab isn’t open, the tools don’t exist. That rules out batch or scheduled agentic work against a WebMCP site, for now.

Discoverability is thin. An agent has to visit your page to see your tools. There’s no global registry, no “hey agent, here’s a list of sites with useful WebMCP tools” index. A .well-known/webmcp manifest has been proposed – and I think it’ll be necessary eventually – but nothing’s shipped yet. Someone is going to come up with an authority directory of WebMCP supportive brands any minute now.

The spec moves weekly. Between my first discovery of the docs and shipping, my implementation, provideContext and clearContext got removed entirely, unregisterTool came back after being briefly deprecated, and the AbortSignal handling in registerTool‘s second argument settled into the form above. Track the spec repo and expect to rewrite things. I’m in the preview group which is very easy to register for.

If you run a site that has structured data behind predictable URLs – a product catalogue, a job board, a docs site, a media library – WebMCP is worth shipping now, even though browser adoption is near zero. It’s cheap to add, it forces you to think about your tool contracts before agents try to guess them, and it positions the site for when Chrome lifts the flag and Edge follows. When that happens I think there will be quite a fuss about it.

The post Implementing WebMCP on a Recruitment Website appeared first on Houtini.

I Built a Schema Migration Tool for Cassandra Because Nothing Else Worked

Mon, 20 Apr 2026 09:12:48 +0000

Flyway and Liquibase treat Cassandra like PostgreSQL. They miss async DDL, distributed locking, and partial failures. So I built cqltrack — open-source CLI + Python library with schema agreement, LWT locking, and a CQL linter.

And then open-sourced it.

If you manage Apache Cassandra in production, you've felt this pain. You need to add a column, create an index, or restructure a table. So you SSH into a node, open cqlsh, and paste your CQL. Then you do it again on staging. Then someone on your team does the same change slightly differently on another cluster.

Sound familiar?

I looked at existing tools. Flyway has a Cassandra plugin. Liquibase can talk CQL. But they all treat Cassandra like PostgreSQL with a different query language. They miss the hard parts:

DDL is asynchronous. When you CREATE TABLE, the coordinator returns success before all nodes know the table exists. Your next statement — CREATE INDEX on that table — lands on a different node that hasn't seen it yet. It fails. Flyway doesn't handle this. Neither does Liquibase.

There are no DDL transactions. If statement 3 of 5 fails, statements 1 and 2 already executed. You can't roll back. Your database is in a half-migrated state.

Multiple processes can migrate simultaneously. Two CI runners deploying to the same cluster. Both see pending migrations. Both try to apply them. Chaos.

So I built cql-track.

What It Does

cqltrack is a schema migration tool that actually understands Cassandra's distributed nature. Install it with pip:

pip install cql-track

14 commands. One CLI. Everything you need:

cqltrack init         Create keyspace + tracking tables
cqltrack migrate      Apply pending migrations
cqltrack rollback     Undo migrations
cqltrack status       Applied vs pending at a glance
cqltrack history      Full audit trail with timing
cqltrack lint         Static analysis for dangerous CQL
cqltrack diff         Compare schemas across environments
cqltrack snapshot     Export live schema as CQL
cqltrack baseline     Adopt on existing databases
cqltrack pending      CI gate — exit code 1 if unapplied
cqltrack validate     Detect modified migration files
cqltrack repair       Accept intentional file changes
cqltrack new          Scaffold a migration file
cqltrack profiles     List environment profiles

But the real value is in what happens under the hood.

Architecture

Two entry points — CLI for terminal/CI, Python API for embedding in applications. Same engine underneath.

Schema Agreement — The Problem Nobody Talks About

Cassandra propagates schema changes through gossip. After a DDL statement, nodes converge asynchronously. The common "fix" is sleep(5). That's not a fix.

cqltrack polls system.local and system.peers after every DDL statement, waiting until all nodes report the same schema_version UUID. Only then does it proceed.

Configurable timeout (default: 30s). DML statements (INSERT, UPDATE) skip this entirely — they don't need agreement.

Distributed Locking with Cassandra's Own LWT

No external dependencies. No ZooKeeper. No Redis. cqltrack uses Cassandra's Lightweight Transactions to implement a distributed lock.

When two CI runners or Kubernetes pods try to migrate simultaneously:

Key design decisions:

TTL safety net — if a worker crashes without releasing, the lock auto-expires in 10 minutes
Ownership check — DELETE IF owner = me prevents one process from releasing another's lock
SERIAL consistency — full linearizability regardless of your configured consistency level
30 retries, 2s intervals — patient waiting before giving up

Partial Failure Tracking

Statement 3 fails. Statements 1 and 2 already ran. Cassandra has no rollback.

When a migration fails:

It's recorded in the history table with status = failed
cqltrack status shows it as pending — ready for retry
cqltrack history shows it as FAILED — full audit trail
Fix the CQL file, run migrate again — clean retry

The linter helps prevent retryability issues. It warns you if you write CREATE TABLE without IF NOT EXISTS — because on retry, that statement would fail even though the table already exists from the first attempt.

Not Just a CLI — A Python Library

Starting from v1.1.0, cqltrack works as a programmatic API. Embed migrations directly in your application startup:

FastAPI:

from contextlib import asynccontextmanager
from fastapi import FastAPI
from cqltrack import CqlTrack

@asynccontextmanager
async def lifespan(app: FastAPI):
    with CqlTrack("cqltrack.yml") as tracker:
        tracker.init()
        tracker.migrate()
        yield

app = FastAPI(lifespan=lifespan)

Django:

from django.apps import AppConfig
from cqltrack import CqlTrack

class MyAppConfig(AppConfig):
    def ready(self):
        with CqlTrack("cqltrack.yml") as tracker:
            tracker.init()
            tracker.migrate()

Plain Python — no YAML needed:

from cqltrack import CqlTrack

with CqlTrack(contact_points=["127.0.0.1"], keyspace="my_app") as t:
    t.init()
    t.migrate()

The distributed lock ensures only one Gunicorn worker or Kubernetes pod runs migrations. Others wait, then find nothing pending.

Built-in Static Analysis

8 rules that catch real problems:

Rule	What it catches
`no-rollback`	Missing `@down` section
`empty-rollback`	Empty rollback — false sense of safety
`drop-no-if-exists`	`DROP TABLE` without `IF EXISTS` — not idempotent
`create-no-if-not-exists`	`CREATE TABLE` without `IF NOT EXISTS`
`column-drop`	`ALTER TABLE DROP` in UP section — permanent data loss
`truncate`	`TRUNCATE` — wipes all data
`pk-alter`	PRIMARY KEY change — impossible in Cassandra
`type-change`	Column type change — very limited support

Context-aware: ALTER TABLE DROP in @down (rollback) is expected and not flagged. No running Cassandra needed.

Schema Diff Across Environments

$ cqltrack diff --source dev --target prod

Schema diff: myapp_dev <-> myapp_prod

  table       audit_log                     only in dev
  column      users.phone                   only in dev        text
  index       idx_users_email               only in dev

3 difference(s) found.

Compares tables, columns (with types), partition keys, clustering keys, indexes, and UDTs. Works across clusters via profiles or between keyspaces on the same cluster.

Multi-Environment Profiles

One YAML file. All environments:

profiles:
  dev:
    keyspace:
      name: myapp_dev
  prod:
    cassandra:
      contact_points: [prod-1, prod-2, prod-3]
      consistency: LOCAL_QUORUM
    keyspace:
      name: myapp_prod

cqltrack --profile prod migrate
cqltrack --profile dev diff --target-profile prod

Config resolution (last wins):

The Full Migration Lifecycle

How It Compares

| | cassandra-migrate | cassandra-migration | cqltrack |
|---|:-:|:-:|:-:|
| Schema agreement | No | No | Yes |
| Distributed lock (LWT) | No | Basic | Yes + TTL |
| Partial failure tracking | No | No | Yes |
| CQL linter | No | No | 8 rules |
| Schema diff | No | No | Yes |
| Multi-env profiles | No | No | Yes |
| JSON output for CI | No | No | Yes |
| Astra DB | No | No | Yes |
| Baseline adoption | No | No | Yes |
| Programmatic API | No | No | Yes |

Compatibility

Verified with:

Apache Cassandra 3.x, 4.x, 5.x
DataStax Enterprise (DSE)
DataStax Astra DB (cloud)

AWS Keyspaces is not supported yet — it doesn't support Lightweight Transactions the way open-source Cassandra does. It's on the roadmap.

Get Started

pip install cql-track

GitHub: github.com/ereshzealous/cql-track
PyPI: pypi.org/project/cql-track
Docs: USAGE.md
Examples: FastAPI, Django, plain Python

MIT licensed. Contributions welcome.

If you've struggled with Cassandra schema management, give it a try. Star the repo if it saves you time.

If you get a chance to try it out, I'd appreciate any feedback. Feel free to open an issue at github.com/ereshzealous/cql-track/issues if you run into anything.

Schemity vs dbdiagram.io: When Your ERD Tool Needs to Outlive the Meeting

Tue, 07 Apr 2026 02:32:05 +0000

There's a moment every software engineer knows.

You're explaining a new feature to a teammate. The schema is in your head. You need something visual, fast, right now. You open a browser tab, type dbdiagram.io, and in three minutes you have a diagram you can paste into Slack.

The meeting happens. Everyone nods. The diagram link dies in the chat history. The actual schema lives in your database, unrelated to what you drew.

That's not a failure of discipline. That's the ceiling of the tool.

This article is for engineers who have hit that ceiling and are wondering what comes next.

The Honest Summary

dbdiagram.io is a fast, focused ERD tool built for quick sketching. Fast, free, browser-based, zero friction. If you need a diagram for a meeting and you'll never look at it again, nothing beats it.

Schemity is what you use when the diagram needs to outlive the meeting. When your ERD is part of your codebase, not a link in Slack. When you want to go from sketch to production schema without switching tools.

If that distinction doesn't matter to you yet, use dbdiagram.io. It's genuinely excellent at what it does.

If it does matter, read on.

Side-by-Side

	dbdiagram.io	Schemity
Interface	Code-based (DBML syntax)	Visual drag-and-drop
Platform	Browser only	Native desktop (macOS, Windows, Linux)
Install size	None (web)	9 MB
Offline	No	Full offline, air-gap ready
Free tier	10 public diagrams, no private, 1 viewer	2-week full trial, all features
Privacy / diagram limits	Upgrade to $9/month required	2-week full trial, fully usable forever after
Your data location	Their servers	Your machine, plain JSON
Git workflow	Manual export	Native: ERD is a JSON file in your repo
Live DB sync	Limited: export SQL scripts only, no direct sync	Yes: reverse-engineer, sync, generate migrations
Migration generation	No	Yes: exact SQL diff, useful for POC and personal projects
Pricing	$9/month	$129 one-time
Keyboard shortcuts	Minimal	Keyboard-first, every action has a shortcut
Multiple tabs	Browser tabs only, no isolated undo history	Yes: native tabs with isolated undo history per diagram
Constraints & indexes	Basic	Full: unique together, check constraints, indexes
N:N relationships	Manual	Auto-generated junction table
Relationship line routing	Fixed, no control	Custom waypoints, smart rerouting, full manual control

Where dbdiagram.io Wins

Let's be honest about this. dbdiagram.io does several things better than almost any alternative.

Speed from zero. No download. No account required. Open browser, start typing, diagram appears in real time. For the specific use case of "I need an ERD right now," nothing is faster.

DBML syntax. If you think in code, DBML is elegant. Define a table in four lines. Copy it from your ORM model. The keyboard never leaves the home row. For engineers who find drag-and-drop slower than typing, this is genuinely the right interface.

Sharing is trivial. One link. Anyone can view it. No account needed for viewers. For sharing with non-technical stakeholders or across teams, the link-based sharing model is hard to beat.

Free. For individual use up to 10 diagrams, you pay nothing. For a lot of engineers, that's enough.

Where dbdiagram.io Hits Its Ceiling

The diagram is not your schema. It's a picture of your schema.

This is the fundamental problem. dbdiagram.io creates a visualization. It doesn't connect to your database. It doesn't track changes. It doesn't generate migrations. When your schema evolves (and it always does), your diagram falls behind. Within weeks, the link you shared is a historical artifact, not a current document.

Your data lives on their servers, not yours.

Every diagram you create in dbdiagram.io is stored on Holistics' infrastructure. If they shut down, your diagrams disappear. If your company requires data locality (SOC 2, ISO 27001, regulated industries), a browser tool storing your schema on a third-party server is a compliance question you'd rather not answer.

The free tier is a public diagram trap.

The free tier gives you 10 diagrams, all public, all visible to anyone with the link, with no private option. The moment you need diagram number 11, or your first private diagram, the pricing jumps to $9/month. For most engineers working on real projects, "public diagrams only" is a non-starter from day one. Your schema is not a public document.

No offline.

Working on a flight. Behind a corporate firewall. On a client site with restricted internet. dbdiagram.io simply doesn't work. For a tool that's supposed to help you think through your architecture, internet dependency is a real constraint.

DBML has a learning curve for non-coders.

If you're the senior engineer who thinks in SQL, DBML feels natural. If you're onboarding a junior, or collaborating with a data analyst who doesn't write SQL daily, the code-first interface creates friction. The visual feedback is good, but the input method is a barrier.

The Three Failure Modes Schemity Was Built to Solve

Schemity wasn't built to compete with dbdiagram.io on its own terms. It was built to solve three specific failure modes that exist across the entire ERD tool market.

Failure Mode 1: The tool defeats you before you start

Visual Paradigm is a serious modeling tool. It does have a Community edition that is free. But finding it is its own obstacle. The download page is cluttered with editions, pricing tiers, and license options that make it genuinely unclear which version to download. Engineers who just want to start modeling end up reading licensing FAQs instead of drawing tables.

Once you do find the right download, the installer takes over. JVM dependency, license wizard, 200+ MB download. Motivated engineers have abandoned it before creating a single entity. The tool defeated them before they opened it.

Schemity is 9 MB. It starts in seconds. There is no IT ticket, no JRE installation, no license wizard, no edition confusion. One download, one version, running immediately. The activation energy is low enough that you open it before the meeting, not after.

Failure Mode 2: Fast sketching and serious design are mutually exclusive

The market has forced a false choice: either use a basic tool that's fast (dbdiagram.io) or use an enterprise tool that's serious (Visual Paradigm, erwin). There is almost nothing in between.

Schemity is drag-and-drop fast. Keyboard shortcuts make it faster still once you're comfortable. But the same tool that handles a five-minute sketch also handles a production schema with 100+ tables, composite unique constraints, check constraints, indexes, and SSH-connected live database sync. It can also generate SQL migrations directly from your ERD, useful for personal projects and fast POCs where you don't need a full migration framework in the way. For production team workflows, your existing migration tooling stays in charge. Schemity sits alongside it, not in front of it.

You don't graduate to another tool. You just use more of the same tool.

Failure Mode 3: Trial expiry holds your work hostage

This is the fear nobody talks about in ERD tool marketing. You spend two hours in a trial. The trial expires. Your diagrams are either gone or locked behind a paywall. And if you were on dbdiagram.io's free tier the whole time, your schema was public to anyone with the link. Serious, sensitive work sitting on a public URL without you realizing it.

Schemity's answer to this is architectural, not a policy. Your ERDs are plain JSON files in ~/schemity/ on your own machine. When the trial expires, Schemity stops receiving updates. You get a single friendly reminder when you open the app, once per session, not a popup that blocks your work or repeats every five minutes. Everything else works exactly as before. Your files are yours. They always were.

If Schemity shuts down as a business tomorrow, your diagrams open perfectly on Monday.

The Git Workflow Nobody Else Has

This is the feature that changes how a team works with database design.

In dbdiagram.io, your ERD lives at a URL. You share the link. When the schema changes, someone updates the diagram manually, if they remember. The diagram and the codebase drift apart over time. Within months, the link you shared in Slack is a historical artifact, not a current document.

Schemity takes a fundamentally different approach, one borrowed from how mature engineering teams already handle infrastructure.

Nobody commits Terraform files inside an application service repo. Infrastructure is a shared concern, it spans services, it has its own change cadence, it deserves its own review. So it lives in its own repo.

Your database schema deserves the same treatment.

The pattern Schemity enables is an ERD repo: a single, dedicated repository that holds the ERDs for every service in your company.

company-erd-repo/
  ├── payment-service/
  ├── user-service/
  ├── notification-service/
  └── legacy-crm/

Each folder is a Schemity workspace containing plain JSON files. The entire repo lives as ~/schemity/ on every engineer's machine. Schemity opens it as a central hub.

Schemity does not stand in your workflow. It does not replace your migration tool. Your schema changes still flow through whatever your team already uses: Django, Rails, Flyway, Atlas, anything. Schemity sits alongside that workflow, not in front of it.

Here is what it looks like in practice:

For the engineer making the change: Clone company-erd-repo once into ~/schemity/. Run your migration as normal. Once it is applied to your local database, open Schemity, connect to it, and let it reflect the current state. Arrange the entities, update the relationships, add legends to give the diagram business meaning. Commit the updated JSON and open a PR against the ERD repo.

For the engineer reviewing the change: Pull the branch. Open Schemity. The diff is right there, a JSON file change that maps directly to a visual diagram. No migration file archaeology. No mental reconstruction of what the schema looked like before.

For the architect reviewing multiple services: One repo. One clone. Every service's schema in one place. No hopping between repos hoping someone committed a diagram.

For the new engineer onboarding:

git clone *Emails are not allowed*:company/erd-repo.git ~/schemity

One command. Every service. Every relationship. Every constraint. The full picture of the company's data model, version-controlled and up to date.

What this unlocks that dbdiagram.io never can:

Schema changes get reviewed like code. When a schema change requires a PR against the ERD repo, the change gets reviewed before it is applied, not after. The history of every schema decision lives in Git: who changed it, when, and why.

The database is always the source of truth. Real teams miss steps. An engineer ships a migration in a busy sprint and forgets to update the ERD. It happens. With dbdiagram.io, that diagram is now wrong and nobody knows it. With Schemity, the next time anyone opens that ERD and connects to the database, Schemity reflects the current state automatically. The new tables are there. The new relationships are there. The new columns are there. The only thing missing is the visual arrangement: where the entities sit on the canvas and how the lines are routed. Drag a few boxes, tidy the lines, commit. No data lost. Nothing out of date. The diagram catches up in minutes, not sprint cycles.

This is separation of concerns applied to the full engineering stack. Source code in service repos. Infrastructure in the infra repo. Schema in the ERD repo.

It is not a feature dbdiagram.io can add. It would require rethinking what an ERD tool is for.

Pricing: One-Time vs. Monthly

dbdiagram.io: $9/month ($108/year) once you exceed the free tier.

Schemity: $129 one-time with $69/year renewal for updates (optional, the tool works forever without renewing).

At 14 months, Schemity costs the same as dbdiagram.io's subscription. Every month after that, Schemity is free. If you use it for three years (and engineers tend to stick with tools that work), Schemity costs $129 + $138 = $267 total. dbdiagram.io costs $324 for the same period, and you still don't own it.

The more important pricing difference is philosophical. Schemity's one-time model is a statement: the tool is valuable enough that you'll keep using it without being forced to. You don't stay because canceling is painful. You stay because the tool earns it.

Who Should Use dbdiagram.io

You need a diagram in the next five minutes for a meeting
You'll never look at this diagram again after today
You're communicating a schema idea, not building one
You think in DBML and the code-first interface is faster for you
The diagram doesn't need to live anywhere except a Slack link

dbdiagram.io is excellent for this use case. Use it without guilt.

Who Should Use Schemity

You need the diagram to still be accurate next month
Your ERD belongs in your repository, not in someone else's cloud
You work offline, behind a VPN, or in a restricted environment
You're graduating from a basic tool without wanting a tool that feels like an enterprise installation ceremony
You want to generate migrations directly from your design for a personal project or fast POC, without a full migration framework in the way
You're a senior engineer recommending a tool to a junior who shouldn't be defeated by the installer

The Bottom Line

dbdiagram.io is a sketch pad. It's a very good sketch pad.

Schemity is a design tool that happens to be as fast as a sketch pad.

The question is not which tool is better in absolute terms. The question is whether your ERD is a communication artifact that lives in a meeting, or a design artifact that lives in your codebase.

If it's the latter, Schemity was built for you: https://schemity.com

Gnoke Dataforge

Sat, 14 Mar 2026 06:32:54 +0000

The Community

Vibe developers — people who ship fast with AI assistants like Claude, Cursor, or ChatGPT.

One thing I've learned after years of building: when you hand an AI assistant a well-structured schema upfront, it hallucinates less, asks fewer clarifying questions, and produces far better code. But there was no lightweight, offline-first tool to quickly model a table and export it in AI-ready formats. So I built one.

What I Built

Gnoke DataForge — a browser-based relational schema modeler that runs 100% offline.

You open it, design your tables visually, define column types and constraints (PK, NOT NULL, UNIQUE), and export in formats your AI assistant can immediately use:

.json — flat data format
.entity.json — structured entity format ideal for pasting into AI prompts
.sql — CREATE TABLE + INSERT statements
.sqlite — a real binary SQLite database file
.csv — universal fallback

Projects are saved locally via IndexedDB. No account. No server. No telemetry.

Demo

???? Live: https://edmundsparrow.github.io/gnoke-dataforge

Open it, edit the demo table, switch to SQLite mode to define types and constraints, then hit Export — all without leaving the browser.

Code

{% embed https://github.com/edmundsparrow/gnoke-dataforge %}

How I Built It

The entire app is vanilla HTML, CSS, and JavaScript — no framework, no build step.

SQLite in the browser via sql.js (WebAssembly) — handles .sqlite export and import
IndexedDB for local project persistence — each saved table is stored as a real SQLite binary blob
A custom JSON normalizer that accepts multiple JSON shapes (array of objects, entity format, flat arrays) so importing from AI-generated output just works
Light/dark theme, mobile drawer, and a skip-intro toggle for repeat visits

The design prioritizes speed: open → build → export → paste into AI. That's the whole loop.

Coder Legion - Recent posts tagged schema

SEO Checklist for Indie Hackers: Sitemap, Schema, and llms.txt — the Three Files That Do the Talking

1. The sitemap: prove every page exists

2. Schema: tell machines what the page IS

3. llms.txt: the file for readers that are not browsers

The whole checklist, on one screen

Google killed FAQ rich results in May 2026. Stop selling FAQ schema as an AI ranking trick.

The timeline

What FAQPage still does

What it no longer does

What to do on a store

What Is Structured Data? A Plain-Language Guide to Schema Markup

What Is Structured Data? A Plain-Language Guide to Schema Markup

What Structured Data Actually Is

Why It Matters Beyond Just "Being Thorough"

What Structured Data Does Not Do

Common Types of Structured Data Worth Knowing

How Structured Data Actually Gets Added

How to Check If Your Structured Data Is Actually Working

Frequently Asked Questions

Conclusion

Helm Values JSON Schema: Validate Your values.yaml Before It Breaks Production

The Problem: Silent Failures in Production

What Is values.schema.json

Chart Directory Structure

How Helm Uses the Schema

IDE Benefits: Autocompletion and Inline Validation

Building the Schema: A Practical Guide

Key Schema Patterns Explained

additionalProperties: false

$defs for Reusable Definitions

Conditional Validation with if/then/else

Pattern Validation for Image Tags

Enum for Controlled Vocabularies

CI/CD Integration

GitHub Actions

Implementing WebMCP on a Recruitment Website

Why a Recruitment Site?

What’s WebMCP?

How WebMCP Differs From MCP

Getting Set Up

Setting Up the Imperative API

The Declarative API Is Free Engineering

Context-Scoped Tool Registration

Navigation Tools vs Data-Retrieval Tools

What WebMCP Can’t Do (Yet)

I Built a Schema Migration Tool for Cassandra Because Nothing Else Worked

What It Does

Architecture

Schema Agreement — The Problem Nobody Talks About

Distributed Locking with Cassandra's Own LWT

Key design decisions:

Partial Failure Tracking

Not Just a CLI — A Python Library

Built-in Static Analysis

Schema Diff Across Environments

Multi-Environment Profiles

The Full Migration Lifecycle

How It Compares

Compatibility

Get Started

Schemity vs dbdiagram.io: When Your ERD Tool Needs to Outlive the Meeting

The Honest Summary

Side-by-Side

Where dbdiagram.io Wins

Where dbdiagram.io Hits Its Ceiling

The Three Failure Modes Schemity Was Built to Solve

Failure Mode 1: The tool defeats you before you start

Failure Mode 2: Fast sketching and serious design are mutually exclusive

Failure Mode 3: Trial expiry holds your work hostage

The Git Workflow Nobody Else Has

Pricing: One-Time vs. Monthly

Who Should Use dbdiagram.io

Who Should Use Schemity

The Bottom Line

Gnoke Dataforge

The Community

What I Built

Demo

Code