com um clique
tinybird-deploy
// Deploy Tinybird pipes and datasources for enter.pollinations.ai observability. Validates and pushes changes to Tinybird Cloud.
// Deploy Tinybird pipes and datasources for enter.pollinations.ai observability. Validates and pushes changes to Tinybird Cloud.
Add, update, or remove text/image/video/audio/embeddings models. Covers the full lifecycle: files to touch, what to verify, and how to test empirically before merging.
Detect and analyze abusive accounts on Pollinations. IP clustering, multi-signal scoring, ban recommendations. Use when investigating abuse, bot farms, or suspicious usage patterns.
Debug and diagnose model errors in Pollinations services. Analyze logs, find error patterns, identify affected users. For taking action on user tiers, see tier-management skill.
Query billing, usage, credits, and resource deployments across all our cloud and SaaS providers (Azure, AWS, Cloudflare, GCP, Tinybird, Vercel, Stripe, Polar, etc.) via their native CLIs and APIs. Use for any question about provider costs, spend by service/day/month, credit eligibility, invoice totals, which resources are running, or how to deploy/inspect resources. Each provider has a dedicated playbook under `providers/`.
Analyze Pollinations revenue, pack purchases, and tier spending patterns. Query Polar for payment history and Tinybird for usage data.
Generate images, text, audio, video, and transcribe speech via the Pollinations API using the polli CLI. Use when asked to generate media, call pollinations.ai, check pollen balance, list models, manage API keys, or run polli commands.
| name | tinybird-deploy |
| description | Deploy Tinybird pipes and datasources for enter.pollinations.ai observability. Validates and pushes changes to Tinybird Cloud. |
Deploy observability pipes and datasources to Tinybird Cloud.
curl -sSL https://tinybird.co | bash or pip install tinybird-clienter.pollinations.ai/observability directorytb login if needed)Two workspaces, same region (gcp-europe-west2). Pipes and datasources must be kept in sync across both.
| Workspace | Receives traffic from | UI |
|---|---|---|
pollinations_enter | production worker only | https://cloud.tinybird.co/gcp/europe-west2/pollinations_enter |
pollinations_enter_staging | staging worker + dev worker + local npm run dev | https://cloud.tinybird.co/gcp/europe-west2/pollinations_enter_staging |
Workspace routing is purely token-scoped — same regional ingest URL, different TINYBIRD_INGEST_TOKEN per environment (set in secrets/{prod,staging,dev}.vars.json).
The local .tinyb is gitignored and points to the prod workspace by default. To target the staging workspace, set TB_TOKEN to a staging admin token for any single command (don't run tb workspace use — it tends to fail; the env var is the reliable override).
enter.pollinations.ai/observability/
├── datasources/ # Data source definitions (.datasource)
│ ├── generation_event.datasource
│ ├── polar_event.datasource
│ ├── stripe_event.datasource
│ └── ...
└── endpoints/ # Pipe definitions (.pipe)
├── weekly_usage_stats.pipe
├── weekly_active_users.pipe
├── daily_stripe_revenue.pipe
└── ...
Always validate before deploying. Dry-run is safe to run anytime against either workspace.
cd enter.pollinations.ai/observability
# Against prod workspace (default — uses local .tinyb token)
tb --cloud deploy --check --wait
# Against staging workspace
TB_TOKEN=<staging_admin_token> tb --cloud deploy --check --wait
Example output:
| status | name | type | path |
|----------|-----------------------|----------|--------------------------------------|
| modified | weekly_usage_stats | endpoint | endpoints/weekly_usage_stats.pipe |
If validation passes, deploy to both workspaces. Recommended order: staging first, then prod — if staging breaks you catch it before touching prod.
# 1. Deploy to staging first
TB_TOKEN=<staging_admin_token> tb --cloud deploy --wait
# 2. Verify behavior on staging (e.g. curl a pipe via staging read token)
# 3. Deploy to prod
tb --cloud deploy --wait
Skipping the staging step is a known drift vector — see issue #11127 for the planned CI auto-deploy that will enforce this.
Test the deployed pipe. Use the read token for whichever workspace you deployed to.
# Prod read token (decrypted from sops-encrypted prod secrets)
TINYBIRD_TOKEN=$(SOPS_AGE_KEY=$(security find-generic-password -a "$USER" -s sops-age-key -w) \
sops -d ../secrets/prod.vars.json | jq -r '.TINYBIRD_READ_TOKEN')
# Test the pipe
curl -s "https://api.europe-west2.gcp.tinybird.co/v0/pipes/weekly_usage_stats.json?weeks_back=12" \
-H "Authorization: Bearer $TINYBIRD_TOKEN" | jq '.data | length'
For staging, swap prod.vars.json → staging.vars.json.
| Flag | Description |
|---|---|
--check | Validates without making changes (dry run) |
--wait | Waits for deployment to complete |
--no-allow-destructive-operations | Prevents removing datasources (default) |
--allow-destructive-operations | Required to delete datasources |
.pipe file in endpoints/Same as above — edit, validate against both, deploy staging then prod.
curl -sSL https://tinybird.co | bash
# Or
pip install tinybird-cli
tb login
# Follow prompts to authenticate
If a pipe times out with large weeks_back:
uniq() instead of uniqExact() for user counts (~10x faster)--cloud: Without it, CLI tries to use Tinybird Local (Docker)tb push: It's deprecated, use tb --cloud deploy