Your first deploy with Ghostable

Follow these steps to take a project from zero to first deploy with Ghostable. You will initialize the CLI, define a schema, push environment variables securely, add validation to your pipeline, and run a deploy that refuses to ship broken config.

What you'll do

Initialize Ghostable in your repo so environments are linked to your project.
Create a shared schema that documents and validates required env vars.
Push secrets securely without committing raw values.
Validate locally and in CI so deploys fail fast on bad config.
Deploy with confidence using a deploy token instead of a personal token.

Prerequisites

Ghostable CLI installed.
A deploy/machine token stored as GHOSTABLE_TOKEN in CI (or a local login token while testing).
Project repo with a .env you can sanitize and push.
Access to your app's deploy pipeline (GitHub Actions example below).

1. Initialize Ghostable

Link your repo to a Ghostable project. This writes .ghostable/ghostable.yaml with project + environment info (no secrets stored here).

ghostable init
# follow prompts for org/project

Commit .ghostable/ghostable.yaml so teammates share the same project wiring.

2. Define your schema

Add a schema to document and validate required variables. Start global, then add overrides for production.

# .ghostable/schema.yaml
APP_NAME:
  - required
  - string
  - max:64

APP_ENV:
  - required
  - in:local,staging,production

APP_URL:
  - required
  - url

DB_CONNECTION:
  - required
  - in:mysql,pgsql,sqlsrv,sqlite

LOG_CHANNEL:
  - required
  - in:stack,stdout

# .ghostable/schemas/production.yaml
APP_DEBUG:
  - required
  - boolean
  - in:false

APP_KEY:
  - required
  - starts_with:base64:
  - min:44

QUEUE_CONNECTION:
  - required
  - in:redis,sqs

3. Push env vars securely

Sanitize your local .env (no production secrets committed) and push values to Ghostable for your target environment.

ghostable login --token "$GHOSTABLE_TOKEN"
ghostable env push --env production --file .env.production

This encrypts locally with your device key and sends only ciphertext + metadata. Ghostable never sees plaintext values.

4. Validate before deploy

Run validation locally to catch issues early. It merges schema.yaml with the environment override and checks your .env.

ghostable env validate --env production --file .env.production

Fix any failing keys before you move to CI or release.

5. Wire CI for deploys

Add a job that logs in with a deploy token, validates, and only then runs your deploy step. Example: GitHub Actions.

name: Deploy

on:
  workflow_dispatch:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install @ghostable/cli@latest
      - name: Validate env
        env:
          GHOSTABLE_TOKEN: ${{ secrets.GHOSTABLE_TOKEN }}
        run: |
          ghostable login --token "$GHOSTABLE_TOKEN"
          ghostable env validate --env production --file .env.production
      - name: Deploy app
        env:
          GHOSTABLE_TOKEN: ${{ secrets.GHOSTABLE_TOKEN }}
        run: |
          ghostable deploy

If validation fails, the job exits non-zero and the deploy is blocked.

6. Deploy with confidence

With schema + validation enforced, run your deploy job. Because secrets and schemas stay local, you avoid leaking values while still catching misconfigurations.

What not to do

Don't skip validation in CI; a local-only check won't protect production deploys.
Don't use personal tokens in pipelines - use deploy/machine tokens with least privilege.
Don't commit real secrets to .env or schema.yaml; keep them in Ghostable and inject at runtime.
Don't maintain drift between environments; push/pull regularly and keep schemas in version control.

Next steps

Add staging/preview schemas that mirror production to surface issues earlier.
Use ghostable env pull in review apps to hydrate from safe sources instead of copying .env files.
Extend validation rules with regex and starts_with for API keys and URLs.
Keep reading the validation docs and environment basics for more patterns.