Your first deploy with Ghostable | Ghostable                           On this page

- [What you'll do](#what-youll-do)
- [Prerequisites](#prerequisites)
- [1. Initialize Ghostable](#step-1)
- [2. Define your schema](#step-2)
- [3. Push env vars securely](#step-3)
- [4. Validate before deploy](#step-4)
- [5. Wire CI for deploys](#step-5)
- [6. Deploy with confidence](#step-6)
- [What not to do](#anti-patterns)
- [Next steps](#next-steps)

 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).

```bash
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.

```yaml
# .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

```

```yaml
# .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.

```bash
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`.

```bash
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.

```yaml
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](https://docs.ghostable.dev/v2/digging-deeper/validation) and [environment basics](https://docs.ghostable.dev/v2/the-basics/environments) for more patterns.

 Tags

 [  deployments  ](https://ghostable.dev/learn/tag/deployments) [  ci-cd  ](https://ghostable.dev/learn/tag/ci-cd) [  env-files  ](https://ghostable.dev/learn/tag/env-files) [  ghostable-cli  ](https://ghostable.dev/learn/tag/ghostable-cli)

 On this page

- [What you'll do](#what-youll-do)
- [Prerequisites](#prerequisites)
- [1. Initialize Ghostable](#step-1)
- [2. Define your schema](#step-2)
- [3. Push env vars securely](#step-3)
- [4. Validate before deploy](#step-4)
- [5. Wire CI for deploys](#step-5)
- [6. Deploy with confidence](#step-6)
- [What not to do](#anti-patterns)
- [Next steps](#next-steps)

 [   Back to Learn ](https://ghostable.dev/learn) [ View docs ](https://docs.ghostable.dev/v2/the-basics/environments)

  Want product news and updates?
--------------------------------

 Sign up for our newsletter.

   Email Address

  Subscribe →    Subscribing...

We care about your data. Read our [privacy policy](https://ghostable.dev/privacy).