Create and manage InsForge projects using the CLI. Handles authentication, project setup, database management, edge functions, storage, deployments, and secr...
name: insforge-cli
description: Create and manage InsForge projects using the CLI. Handles authentication, project setup, database management, edge functions, storage, deployments, and secrets. For writing application code with the InsForge SDK, use the insforge (SDK) skill instead.
license: Apache-2.0
metadata:
author: insforge
version: "1.0.0"
organization: InsForge
date: February 2026
InsForge CLI
Command-line tool for managing InsForge Backend-as-a-Service projects.
> For writing application code with the InsForge SDK, use the insforge (SDK) skill instead, and use the insforge docs to get specific SDK documentation.
Non-Obvious Behaviors
Functions invoke URL: invoked at {oss_host}/functions/{slug} β NOT /api/functions/{slug}. Exits with code 1 on HTTP 400+.
Secrets delete is soft: marks the secret inactive, not destroyed. Restore with insforge secrets update KEY --active true. Use --all with secrets list to see inactive ones.
Storage delete-bucket is hard: deletes the bucket and every object inside it permanently.
db rpc uses GET or POST: no --data β GET; with --data β POST.
Schedules use 5-field cron only: minute hour day month day-of-week. 6-field (with seconds) is NOT supported. Headers can reference secrets with ${{secrets.KEY_NAME}}.
Common Workflows
Set up database schema
insforge db query "CREATE TABLE posts (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
title TEXT NOT NULL,
content TEXT,
author_id UUID REFERENCES auth.users(id),
created_at TIMESTAMPTZ DEFAULT now()
)"
insforge db query "ALTER TABLE posts ENABLE ROW LEVEL SECURITY"
insforge db query "CREATE POLICY \"public_read\" ON posts FOR SELECT USING (true)"
insforge db query "CREATE POLICY \"owner_write\" ON posts FOR INSERT WITH CHECK (auth.uid() = author_id)"
> FK to users: always auth.users(id). RLS current user: auth.uid().
Secrets are resolved at schedule creation/update time. If a referenced secret doesn't exist, the operation fails with a 404 error.
#### Best Practices
1. Use 5-field cron expressions only
- pg_cron does not support seconds (6-field format)
- Example: */5 * * * * for every 5 minutes
2. Store sensitive values as secrets
- Use ${{secrets.KEY_NAME}} in headers for API keys and tokens
- Create secrets first via the secrets API before referencing them
3. Target InsForge functions for serverless tasks
- Use the function URL format: https://your-project.region.insforge.app/functions/{slug}
- Ensure the target function exists and has status: "active"
4. Monitor execution logs
- Check logs regularly to ensure schedules are running successfully
- Look for non-200 status codes and failed executions
#### Common Mistakes
| Mistake | Solution |
|---------|----------|
| Using 6-field cron (with seconds) | Use 5-field format only: minute hour day month day-of-week |
| Referencing non-existent secret | Create the secret first via secrets API |
| Targeting non-existent function | Verify function exists and is active before scheduling |
| Schedule not running | Check isActive is true and cron expression is valid |
#### Recommended Workflow
1. Create secrets if needed -> insforge secrets add KEY VALUE
2. Create/verify target function -> insforge functions list
3. Create schedule -> insforge schedules create
4. Verify schedule is active -> insforge schedules get
5. Monitor execution logs -> insforge schedules logs
oss_host is the base URL for all SDK and API operations. api_key is the admin key for backend API calls.
> Never commit this file to version control or share it publicly.
> Do not edit this file manually. Use insforge link to switch projects.
π Tips & Best Practices
1. Use 5-field cron expressions only
- pg_cron does not support seconds (6-field format)
- Example: */5 * * * * for every 5 minutes
2. Store sensitive values as secrets
- Use ${{secrets.KEY_NAME}} in headers for API keys and tokens
- Create secrets first via the secrets API before referencing them
3. Target InsForge functions for serverless tasks
- Use the function URL format: https://your-project.region.insforge.app/functions/{slug}
- Ensure the target function exists and has status: "active"
4. Monitor execution logs
- Check logs regularly to ensure schedules are running successfully
- Look for non-200 status codes and failed executions
#### Common Mistakes
| Mistake | Solution |
|---------|----------|
| Using 6-field cron (with seconds) | Use 5-field format only: minute hour day month day-of-week |
| Referencing non-existent secret | Create the secret first via secrets API |
| Targeting non-existent function | Verify function exists and is active before scheduling |
| Schedule not running | Check isActive is true and cron expression is valid |
#### Recommended Workflow
1. Create secrets if needed -> insforge secrets add KEY VALUE
2. Create/verify target function -> insforge functions list
3. Create schedule -> insforge schedules create
4. Verify schedule is active -> insforge schedules get
5. Monitor execution logs -> insforge schedules logs