Getting Started

Introduction

Lithos is Roblox infrastructure-as-code. It keeps your config, persisted state, and the live Roblox API in sync so every deploy is reviewable and repeatable.

If you have used Terraform, Pulumi, or AWS CDK before, the model will feel familiar. If you have not, this page covers everything you need.

Preview first

Stateful Roblox deploys with drift reconciliation built in.

Lithos turns Creator Hub metadata into reviewable infrastructure-as-code, so teams can plan changes, ship only the intended mutations, and roll back from recorded checkpoints when a deploy goes sideways.

Get started View on GitHub

Preview every deploy

See exact create, update, and delete operations before Lithos mutates Roblox.

Reconcile drift

Compare recorded state with the live API first, then apply only the changes that still make sense.

Rollback with checkpoints

Each deploy records enough history for `lithos undo` to drive resources back toward the last checkpoint.

Keep environments declarative

Run the same config through `dev` and `prod` without copying Creator Hub checklists by hand.

Deployment model

Every deploy is a reconciliation pass across these three inputs.

Configuration

The desired graph from `lithos.yml` or `lithos.json`.

State

The last successful graph plus recent deployment checkpoints.

Live API

What Roblox actually has right now.

Deploy a real example

Install Lithos, authenticate, and run a full `dev` deployment end-to-end.

Understand state

Learn how checkpoints, reconciliation, and remote state storage work.

Browse the schema

Look up every supported field for experiences, places, badges, passes, and more.

The three things Lithos owns

What	Where it lives	What it represents
Configuration	`lithos.yml` or `lithos.json`	What you want to exist. The source of truth.
State	`.lithos-state.yml` (local or remote)	What Lithos believes exists, plus recent deployment history.
Live API	Roblox + Open Cloud	What actually exists right now.

Every command is a function of those three inputs. deploy reads config, reads state, verifies state against the live API, plans a diff, applies it, and writes new state.

State is what Lithos thinks exists. The live API is what actually exists. When they disagree, Lithos treats it as drift and reconciles before any destructive work. State also stores recent deployment checkpoints — lithos undo rolls back toward them.

Why it matters

Lithos moves the metadata that usually lives in Studio and Creator Hub into source control: place names, server settings, products, passes, badges, thumbnails, social links, voice settings, and more.

Reviewable — a plan preview shows exactly which fields on which resources will change, before any byte hits Roblox.
Reversible — lithos undo rolls back toward the last checkpoint, or revert the YAML and redeploy.
Reproducible — dev and prod share one config with declarative overrides, not parallel checklists.
Predictable in CI — one binary, one state file, one set of secrets.

The shortest possible example

lithos.yml

target:
  experience:
    configuration:
      genre: building
    places:
      start:
        file: game.rbxlx
        configuration:
          name: My Experience

lithos deploy

On first deploy Lithos creates the experience, uploads game.rbxlx, and writes the resulting IDs to state. Run the same command again and it noops unless the inputs changed.

Where to go next

Coming from Mantle? Read Migrating from Mantle.

Getting Started