What Programming Languages Does Open-SEO Use? A Technical Breakdown

Open-SEO is primarily built with TypeScript and TSX, supplemented by JavaScript, SQL, YAML, Dockerfile, Markdown, and JSON for tooling, database operations, and configuration.

The open-seo repository by every-app is a modern full-stack SEO platform that demonstrates contemporary web development patterns. Understanding its programming languages helps developers assess the tech stack, contribute effectively, or evaluate it for similar projects. This analysis covers each language's role, with direct citations to source files and their purposes.

---

TypeScript and TSX: The Core Stack

TypeScript dominates the open-seo codebase, serving both frontend and backend concerns. The project uses JSX/TSX for React components and standard TypeScript for server logic, configurations, and utilities.

Frontend: React with TanStack Router

The client-side application relies on TanStack Router for type-safe routing. In src/router.tsx, the router configuration demonstrates typical patterns:

// src/router.tsx
import { createRouter as createTanStackRouter } from "@tanstack/react-router";
import { routeTree } from "./routeTree.gen";
import { DefaultCatchBoundary } from "./client/components/DefaultCatchBoundary";
import { NotFound } from "./client/components/NotFound";

export function getRouter() {
  const router = createTanStackRouter({
    routeTree,
    defaultPreload: "intent",
    defaultErrorComponent: DefaultCatchBoundary,
    defaultNotFoundComponent: () => <NotFound />,
    scrollRestoration: true,
  });

  return router;
}

Key characteristics:

• routeTree.gen.ts — auto-generated TypeScript definitions for type-safe routing
• scrollRestoration and defaultPreload — modern UX features configured in code
• Components written in TSX with explicit return types

Build and Tooling Configuration

Vite and Drizzle configurations are TypeScript-native:

• web/vite.config.ts — Vite bundler configuration with plugin setup
• drizzle.config.ts — ORM configuration supporting both SQLite and Postgres adapters

These files show TypeScript's utility beyond application logic into toolchain orchestration.

Server-Side Scripts

Utility scripts like scripts/seed-rank-tracking.ts use TypeScript for type-safe database operations:

// scripts/seed-rank-tracking.ts
import { db } from "../src/server/db";
import { seedRankTracking } from "./utils/seed";

async function main() {
  await seedRankTracking(db);
  console.log("✅ Rank-tracking seeded");
  process.exit(0);
}

main().catch((e) => {
  console.error("❌ Seed failed:", e);
  process.exit(1);
});

Run via pnpm ts-node scripts/seed-rank-tracking.ts, this pattern appears throughout the scripts/ directory.

---

JavaScript: Runtime Utilities

While TypeScript dominates, plain JavaScript appears in specific contexts:

• scripts/release-notes.mjs — executed directly by Node.js without compilation
• Compiled output from TypeScript files like cli-auth.ts

ES modules (.mjs extension) signal modern JavaScript usage for tooling that must execute without build steps.

---

SQL: Database Schema and Migrations

Open-SEO uses raw SQL for database migrations, managed by Drizzle ORM. The drizzle-pg/ directory contains versioned migration files:

-- drizzle-pg/0012_dashboard.sql
CREATE TABLE dashboard (
  id          SERIAL PRIMARY KEY,
  user_id     INTEGER NOT NULL,
  created_at  TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  updated_at  TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

• Postgres-focused — naming convention drizzle-pg/ suggests primary Postgres support via SERIAL and TIMESTAMP types
• Version-controlled — numbered migrations (0012, etc.) enable rollback and auditability
• ORM-executed — Drizzle runs these during drizzle-kit migrate operations

---

YAML: Workspace and Infrastructure Configuration

YAML handles structural configuration in open-seo:

File	Purpose
pnpm-workspace.yaml	Declares monorepo packages and workspace boundaries
compose.yaml	Docker Compose stack definition
CI workflow files (implied)	GitHub Actions or similar pipelines

This choice reflects YAML's dominance in DevOps tooling and package manager configuration.

---

Dockerfile: Containerized Deployment

The Dockerfile.selfhost enables self-hosted deployments. This single-purpose language definition supports:

• Reproducible production builds
• Environment-agnostic deployment
• Version-pinned base images for security

---

Markdown and JSON: Documentation and Metadata

Supporting languages round out the stack:

• Markdown — README.md and documentation files
• JSON/JSONC — package.json for package manifests, wrangler.jsonc (with comments) for Cloudflare Workers configuration

JSONC support in wrangler.jsonc shows attention to developer experience—comments in configuration files improve maintainability.

---

Summary

Open-SEO's programming language selection follows modern full-stack conventions:

• TypeScript/TSX — primary language for application code, React components, routing, and configuration
• JavaScript — Node.js utility scripts requiring direct execution
• SQL — database migrations (Postgres-flavored) under Drizzle ORM management
• YAML — workspace and infrastructure configuration
• Dockerfile — container definitions for self-hosting
• Markdown — documentation
• JSON/JSONC — package and tool configuration

This stack prioritizes type safety (TypeScript), developer experience (JSONC, Markdown), and operational flexibility (YAML, Dockerfile, SQL).

---

Frequently Asked Questions

Is Open-SEO fully TypeScript, or does it use plain JavaScript?

Open-SEO is predominantly TypeScript, with TSX files for React components and .ts files for server code. Plain JavaScript appears only in specific utility scripts like scripts/release-notes.mjs that run directly in Node.js without a build step.

What database does Open-SEO support based on its SQL files?

The drizzle-pg/ directory and Postgres-specific syntax (SERIAL, TIMESTAMP) indicate Postgres as the primary supported database. The drizzle.config.ts also references SQLite adapters, suggesting dual-database flexibility.

Why does Open-SEO use YAML instead of JSON for workspace configuration?

YAML's support for comments and reduced syntax verbosity makes it preferable for human-maintained configuration files like pnpm-workspace.yaml and compose.yaml. JSON remains in use for machine-generated or strictly schema-bound files like package.json.

What's the difference between wrangler.json and wrangler.jsonc in the codebase?

wrangler.jsonc uses JSON with Comments format, allowing inline documentation. This improves maintainability for Cloudflare Workers configuration, where deployment settings benefit from explanatory notes that standard JSON prohibits.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}