Tyco brings types to configuration. Schemas specify structure and defaults, and instances use a concise, tabular format for clarity and maintainability.

Key features:

Tyco
str timezone: UTC  # this is a global config setting

Application:       # schema defined first, followed by instance creation
  str service:
  str profile:
  str command: start_app {service}.{profile} -p {port.number}
  Host host:
  Port port: Port(http_web)  # reference to Port instance defined below
  - service: webserver, profile: primary, host: Host(prod-01-us)
  - service: webserver, profile: backup,  host: Host(prod-02-us)
  - service: database,  profile: mysql,   host: Host(prod-02-us), port: Port(http_mysql)
                      
Host:
 *str hostname:  # star character (*) used as reference primary key
  int cores:
  bool hyperthreaded: true
  str os: Debian
  - prod-01-us, cores: 64, hyperthreaded: false
  - prod-02-us, cores: 32, os: Fedora

Port:
 *str name:
  int number:
  - http_web,   80  # can skip field keys when obvious
  - http_mysql, 3306
JSON
{
  "timezone": "UTC",
  "Application": [
    {
      "service": "webserver",
      "profile": "primary",
      "command": "start_app webserver.primary -p 80",
      "host": "prod-01-us",
      "port": "http_web"
    },
    {
      "service": "webserver",
      "profile": "backup",
      "command": "start_app webserver.backup -p 80",
      "host": "prod-02-us",
      "port": "http_web"
    },
    {
      "service": "database",
      "profile": "mysql",
      "command": "start_app database.mysql -p 3306",
      "host": "prod-02-us",
      "port": "http_mysql"
    }
  ],
  "Host": [
    {
      "hostname": "prod-01-us",
      "cores": 64,
      "hyperthreaded": false,
      "os": "Debian"
    },
    {
      "hostname": "prod-02-us",
      "cores": 32,
      "hyperthreaded": true,
      "os": "Fedora"
    }
  ],
  "Port": [
    {
      "name": "http_web",
      "number": 80
    },
    {
      "name": "http_mysql",
      "number": 3306
    }
  ]
}

Tyco vs JSON

  • Readable schema definition: Tyco defines types inline with the data, while JSON requires external schema files or lacks type safety entirely.
  • No redundancy: Tyco uses defaults and templates to avoid repeating values. JSON forces you to specify every field for every object.
  • Comments supported: Tyco has native comment support. JSON doesn't allow comments, making documentation impossible.
  • Cleaner syntax: Tyco eliminates unnecessary braces, brackets, and quotes where they add no value (and trailing commas supported!).
  • Object references: Tyco allows referencing other objects by primary key (e.g., Host(prod-01-us)). JSON requires storing raw strings or duplicating data.

Why Tyco?

Type Safety First

When you write configuration files, you know exactly what structure you need: servers have hostnames and port numbers, databases require connection strings, deployments need environment variables. But traditional formats like JSON and YAML treat everything as unstructured, dynamically-typed dictionaries - leaving it up to users (and your runtime code) to maintain that structure when making changes.

Tyco puts types first. Define your configuration schema once, and the format enforces it everywhere. No more accidental country: NO turning into false, version: 1.20 becoming 1.2, or field names silently changing from timeout to timeOut breaking your application. Tyco eliminates these entire categories of errors by making your intent - the structure of your configuration - explicit and enforced. When your schema says a field is an integer, it's an integer - period.

Built-in Defaults Without Complexity

Beyond type safety, Tyco has built-in defaults that eliminate repetition without the complexity. Other formats force you to choose between verbose duplication, messy nesting, or tricky constructs like YAML's anchors and aliases. Tyco's defaults are simple: declare them in your schema or as separate statements, and instances inherit them automatically. No special syntax to learn, no indirection to untangle - just straightforward, readable configuration that scales.

References and Templating

With built-in references and templating, you define values once and reuse them consistently. Need to reference a database server from multiple services? Use Database(prod-primary) instead of copy-pasting connection strings. Change the server's port? Every reference updates automatically. Your configuration stays DRY, correct, and maintainable.

Scannable Tabular Format

Tyco's tabular format makes configuration instantly scannable. Unlike formats like TOML where each key-value pair requires its own line, Tyco lays out instances horizontally in compact rows. You can see all your servers, databases, or environments at a glance - comparing values, spotting differences, and understanding your entire configuration structure without endless scrolling. The format mirrors how you think about the data: as collections of similar objects with varying properties.

Practical First-Class Features

Tyco includes native support for types you actually use in real-world configurations: dates for schedules and expiration policies, times for cron jobs and timeouts, decimals for precise financial or scientific values, and inline enums when fields should only allow curated choices. Comments let you document your configuration inline, and file includes allow you to split large configs into modular, maintainable pieces. These aren't afterthoughts - they're first-class features designed to make your configuration files practical and production-ready.

Get Started

Read the Spec

Dive into the complete specification to understand Tyco's syntax, type system, and capabilities in detail.

Start Coding

The easiest way to try Tyco is with the Python bindings. Prefer another language? Find a parser for JavaScript, Java, C, and more.