Push and Remove

The foir push and foir remove commands manage the lifecycle of your config on the platform. Push creates or updates resources; remove tears them down.

foir push

Reads your config file, sends it to the platform, and creates or updates all declared resources (models, operations, hooks, placements, schedules, segments).

foir push

How Discovery Works

By default, foir push looks for a config file in the current directory. It checks the following file names in order:

1. foir.config.ts
2. foir.config.js
3. foir.config.mjs
4. foir.config.json

The first file found is loaded and pushed.

Specifying a Config File

Use the --config flag to point to a specific file:

foir push --config ./path/to/my-config.ts

Force Reinstall

The --force flag deletes the existing config and all its resources, then recreates everything from scratch:

foir push --force

Use --force when you need a clean slate — for example, if you have renamed model keys or need to reset all records. Without --force, push performs an incremental update.

What Happens on Push

When you run foir push:

1. The CLI loads and validates your config file (must have key and name fields)
2. The config is sent to the platform via the applyConfig API
3. The platform creates new resources or updates existing ones to match the config
4. The CLI prints the resulting config ID and key

Loading foir.config.ts...
Pushing config "my-app" to platform...

Config applied successfully.

  Config ID:  cfg_abc123
  Config Key: my-app

Idempotent Updates

Pushing the same config multiple times is safe. The platform reconciles the declared state with the current state:

• New resources are created
• Existing resources are updated to match the config

What happens to a resource you remove from the config and push depends on the resource type:

• Hooks, schedules, and segments are reconciled with orphan cleanup. If a hook, schedule, or segment that this config previously created is no longer in the config, the next push deletes it. (Segment cleanup is scoped to segments this config owns; segments created elsewhere are left alone.)
• Models and operations are not auto-deleted. Removing one from the config and pushing leaves the platform resource in place — delete it from the admin app or use foir remove to tear down the entire config.

Caution: Because hooks, schedules, and segments are orphan-cleaned, deleting one from your config and pushing is a destructive operation — the resource and its platform state are removed. Keep an entry in the config (e.g. with isActive: false / enabled: false) if you want to pause it rather than delete it.

Publishing

Schema-shaping resources (models, operations, auth providers, the customer profile schema) have a draft and a published channel. foir push decides what to release automatically:

• New resources auto-publish on create — a brand-new type or mutation can’t break an existing query.
• Additive model changes (a new optional field, for example) auto-publish on push for the same reason.
• Breaking model changes (dropping, renaming, or retyping a field) stay as drafts. Push reports them and leaves them for you to review.
• Updated operations, auth providers, and the profile schema stay as drafts.

Pass --publish to release everything left as a draft in one step, including breaking changes:

foir push --publish

Without it, push prints what it held back and how to release it. You can also publish from the admin app. (Drafts are visible to sk_ keys requesting the draft channel — see Schema Publishing.)

foir remove

Removes a config and all resources it provisioned (models, operations, hooks, schedules, placements, segments).

foir remove <key>

Where <key> is the config key (the key field from your foir.config.ts).

Confirmation Prompt

By default, foir remove asks for confirmation before deleting:

? Remove config "My App" (my-app)? This will delete all its models, operations,
  hooks, and schedules. (y/N)

Skipping Confirmation

Use the --force flag to skip the confirmation prompt (useful in CI/CD):

foir remove my-app --force

Config Lifecycle

A typical config lifecycle follows this pattern:

1. Create

Write your foir.config.ts and push it for the first time:

foir push

All declared resources are created on the platform.

2. Update

Modify your config (add fields, change operations, add hooks) and push again:

foir push

The platform updates existing resources to match. New resources are created.

3. Iterate

Continue modifying and pushing as your project evolves. Each push is an incremental update.

4. Remove

When you no longer need the config and its resources:

foir remove my-app

All provisioned resources are deleted.

CI/CD Integration

Use foir push in your deployment pipeline to keep platform resources in sync with your codebase:

# .github/workflows/deploy.yml
name: Deploy Config
 
on:
  push:
    branches: [main]
    paths: ['foir.config.ts']
 
jobs:
  push-config:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g @foir/cli
      - name: Push config
        env:
          FOIR_API_KEY: ${{ secrets.FOIR_API_KEY }}
        run: foir push

Authentication

Both foir push and foir remove require authentication. Use either:

• Interactive login: Run foir login and foir select-project first
• API key: Set the FOIR_API_KEY environment variable

See Using Foir CLI for full authentication details.

Next Steps

• Config System Overview — What you can define in a config
• Configuration Reference — Full config API reference
• Using Foir CLI — CLI installation, authentication, and commands