Migration snapshot
Shut downPlatform
an Airplane.dev
Airtable announced the acquihire of Airplane.dev on Jan 3, 2024. The Airplane.dev product was sunset March 1, 2024; all accounts were disabled after that date and prepaid contracts were refunded. As of July 2026, the platform has been dead for over 27 months. No OSS release, no data-export window publicly documented.
Typical timeline
8–12 weeks
Typical cost
$13K–$25K (agency, fixed)
Why teams leave an Airplane.dev
Airplane.dev is gone. This is not a migration decision — it is a recovery from a dead dependency. Every Runbook, View, and Task that your team relied on must be rebuilt from scratch.
Platform shut down March 1, 2024
Polybit (Airplane's parent) announced closure on Jan 3, 2024 with 23 days' notice. The service went offline March 1, 2024; all accounts disabled; prepaid contracts refunded.
No code export was provided
Airplane was a proprietary internal-tool platform; no OSS release, no data-export window, and no eject path was made available at shutdown. Code not independently Git-backed before March 1, 2024 is gone.
Inheriting broken automation
Teams acquiring another company or inheriting legacy infrastructure may discover Airplane.dev references in runbooks, cron jobs, or CI pipelines that have not executed since March 2024.
CEO steered users to Windmill or Retool
Airplane's own off-boarding guidance named Windmill (OSS, Apache 2.0) and Retool as the closest alternatives. Neither is a drop-in replacement; both require deliberate rebuild effort.
Silent downstream failures accumulating
Airplane-scheduled tasks that fed downstream systems (reports, alerts, database writes) have been failing silently for 27+ months. The gap in data freshness must be assessed before any rebuild begins.
What can you actually take with you?
There is effectively nothing to export from Airplane — accounts are disabled. Recovery starts from Git-backed scripts, team documentation, and connected database audit trails.
| Asset | Can you export it? | How | Notes |
|---|---|---|---|
| Data | Partial | If Airplane tasks queried your own databases (Postgres, MySQL, etc.) or called external APIs, that data lives in those systems and is accessible directly. Export from your source databases. | Data that existed only in Airplane's execution logs or was never persisted to an external system is unrecoverable. |
| Code | No | Airplane was proprietary; no source export path was provided and accounts are now disabled. Code not separately backed up in Git before March 1, 2024 is gone. | If your team version-controlled Airplane task scripts in Git independently, those files are your starting point. Check github.com/acode/cli if you used the CLI. |
| Design/UI | No | Airplane Views (table-based internal UIs) are not exportable. UI must be rebuilt from scratch. | No recovery path exists for Views. |
| Logic/Workflows | No | Runbooks (multi-step workflows), Sessions, and Scheduled tasks are not exportable. Reconstruction must come from team documentation, runbook screenshots, or memory. | Interview everyone who used the platform; reconstruct from execution logs in connected databases if those logs were written. |
| Users & Auth | No | Airplane managed auth internally. User lists and permissions are unrecoverable. | Re-gather user list from your company directory or from the access-control records of the databases Airplane connected to. |
Swipe the table sideways to see the full breakdown.
Where each piece moves in code
The target stack is Next.js + Supabase/PostgreSQL for product-integrated tooling, or Windmill (OSS) for developer-heavy internal-tool teams. Choose before writing a line of code — the wrong choice doubles rework.
an Airplane.dev
Task (Python/JS/SQL script)
In code
Next.js Server Action or API Route
If you have Git backups, port the logic directly. Otherwise reconstruct from runbook documentation and team interviews.
an Airplane.dev
Runbook (multi-step with manual gates)
In code
Next.js multi-step Server Action + Supabase status table
Add an approval_state enum column to track manual gate status; implement a simple admin UI for gate approvals.
an Airplane.dev
View (table-based internal UI)
In code
Retool, Appsmith (OSS), or a Next.js admin page with Supabase Table
Choose based on team frontend capacity. Retool Cloud for zero-ops teams; custom Next.js for product-integrated tooling.
an Airplane.dev
Session (execution log)
In code
Supabase table with run_id, status, output JSON columns
Recreate the audit trail from day one — do not defer logging as a follow-up.
an Airplane.dev
Schedule (cron trigger)
In code
Vercel Cron Jobs or pg_cron in Supabase
Reconstruct schedule from Airplane documentation or team memory; add alerting on failure from the start.
an Airplane.dev
Permissions model
In code
Supabase Row Level Security + Clerk or NextAuth roles
Map Airplane's role/group model to RLS policies. Re-gather user list from company directory.
an Airplane.dev
Connected resources (DB, API keys)
In code
Supabase Vault or environment variables
Re-enter all connection strings and API keys. Verify each connection before any task goes live.
The migration roadmap
There is no extraction from Airplane — accounts are disabled. The roadmap starts from forensic archaeology: Git history, team interviews, and connected database audit trails.
Phase 1: Forensic Archaeology
1–2 weeks (urgent)- Audit all connected databases for any tables written to exclusively by Airplane tasks — this reveals which automations existed
- Search your Git history for any files with Airplane task code, YAML configs, or API key references
- Interview every team that used Airplane.dev and document every Runbook, its trigger (manual vs scheduled), and its downstream consumer
- Check for any cron entries in server crontabs or CI pipelines that pointed at Airplane webhook URLs — those are dead endpoints
- Identify all downstream consumers of Airplane task outputs (reports, Slack alerts, database writes) and triage by business impact
Watch out: Business logic that was only in Airplane and not documented or Git-backed is permanently lost. Set a bounded time limit per function for reconstruction; do not let archaeology expand indefinitely.
Phase 2: Stack Decision & Foundation
1 week- Choose replacement stack before writing code: Windmill (Apache 2.0) for developer-heavy teams; Retool Cloud for zero-ops teams; Next.js for product-integrated tooling
- Set up the chosen stack with Supabase connection and Vercel deployment pipeline
- Implement audit logging (Supabase run_log table) from day one
- Establish alerting on task failure before any scheduled task goes live
Watch out: Retool self-hosting moved to Enterprise-only as of early 2026. Windmill (OSS, Apache 2.0) requires Rust/TypeScript capacity but is freely self-hostable.
Phase 3: Rebuild by Priority
4–7 weeks- Rebuild tasks that feed live downstream systems first — data freshness gaps in reports and alerts take priority
- Recreate Runbooks with manual gate steps; implement approval-state tracking in Supabase
- Rebuild Views or choose an internal-tool layer (Retool, Appsmith) based on stack decision
- Re-enter all database connection strings and API keys in Supabase Vault; test each connection
- Port any Git-recovered Airplane task scripts to the new runtime
Phase 4: Validation & Decommission
1 week- Validate all rebuilt tasks produce correct output against documented expected behavior
- Remove or redirect any dead Airplane webhook URLs in external services (Slack, GitHub, Stripe)
- Document the new stack architecture and runbook inventory for team onboarding
- Acknowledge the 27-month data gap in any reports that depended on Airplane-scheduled outputs
Three ways to migrate — honestly
Every path has a real trade-off. Here is what each costs, how long it takes, and where it bites.
DIY (with AI tools)
$0–$500 + time
1–3 months part-time
Fits
Teams where the only artifact is a clean Git repo of Airplane task scripts and the scope is limited to porting a few scripts to Vercel Functions.
Risks
Forensic archaeology is time-consuming and unpredictable — undiscovered dependencies extend the timeline. Without prior internal-tool experience, Runbook and View rebuild complexity is easy to underestimate.
Freelancer
$3K–$10K
4–8 weeks
Fits
Teams with recovered Git code and clear documentation of what existed. Works when the scope is a handful of Tasks and no complex Runbooks.
Risks
Freelancers rarely scope forensic archaeology well. Ensure the contract explicitly covers gap analysis and business-logic interviews, not just code porting.
Agency (RapidDev)
Done-for-you$13K–$25K fixed
8–12 weeks
Fits
Teams inheriting this system with unclear scope, significant Runbook complexity, or live downstream systems that have been broken for months.
Risks
Minimal — fixed price covers forensic archaeology, stack decision, full rebuild, audit logging, and cutover. Free scoping call available at rapidevelopers.com.
The real risks — and how to defuse them
Undocumented logic permanently lost
Mitigation: Business logic that existed only in Airplane and was not documented or Git-backed cannot be recovered. Interview everyone who used the platform; reconstruct from execution logs in connected databases if available. Set a bounded time limit per function for reconstruction.
Broken cron dependencies causing silent failures
Mitigation: Airplane-scheduled tasks that fed downstream systems (reports, alerts, data syncs) have been failing silently for 27+ months. Audit all downstream systems for data freshness gaps immediately; triage which broken automations are now business-critical.
Choosing the wrong replacement platform
Mitigation: Retool (Airplane's suggested alternative) moved self-hosting to Enterprise-only as of early 2026. Windmill (Apache 2.0) is the OSS choice for developer-heavy teams. Evaluate before writing code — the wrong choice doubles rework.
Auth and user list unrecoverable
Mitigation: Airplane user lists and permissions cannot be recovered. Re-gather user list from your company directory or from the access-control records of the databases Airplane connected to. Rebuild access control from scratch.
Scope creep during rebuild
Mitigation: Resist the temptation to improve the UI or add features while rebuilding. Rebuild to parity first; enhancements in a separate phase. A parallel-improvement rebuild extends timelines and creates defect risk.
Should you actually migrate?
Migrating is a real project. Sometimes staying is the right call — here is the honest split.
Stay if
- There is no stay option — the platform shut down March 1, 2024 and accounts are disabled
- If you inherited this system and it is completely idle with no live cron dependencies, you may defer the rebuild and document the gap until it becomes blocking
- If the only remaining artifact is a small Git repo of Airplane task scripts, you may need only 1–2 weeks of porting work rather than a full engagement
Migrate if
- Any downstream system still expects Airplane-scheduled outputs — rebuild immediately to restore data integrity
- You have a runbook that customer-facing teams reference; the gap is actively causing manual workarounds
- You are merging with or acquiring a team whose tooling included Airplane.dev
Our honest verdict
This is a rebuild, not a migration. Budget for forensic archaeology of what existed, then a clean implementation on Windmill (OSS), Retool Cloud, or a custom Next.js admin stack. The sooner you audit the gaps, the fewer silent failures your business is carrying.
Do this today: pre-migration checklist
Whatever path you choose, protect yourself first. Work through this before you touch a line of code.
Audit all connected databases for any tables written to exclusively by Airplane tasks
These tables reveal which automations existed and tell you exactly what must be rebuilt to restore data integrity.
Search your entire Git history for files with Airplane task code, YAML configs, or API key references
Git-backed scripts are your primary recovery asset. Everything found here is porting work rather than reconstruction from memory.
Check every external service (Slack, GitHub, Stripe, Airtable) for webhook configurations pointing at Airplane URLs — update or disable immediately
Dead webhook URLs are causing silent failures in production integrations right now. This is the highest-urgency action.
Interview every team that used Airplane.dev and document every Runbook and its trigger
Team memory is the only source of truth for logic that was never Git-backed. Capture it before personnel changes erode it further.
Choose a replacement stack before writing code: Windmill (OSS) for developer-heavy teams; Retool Cloud for zero-ops teams; custom Next.js for product-integrated tooling
The wrong stack choice requires a full rewrite. This decision gates everything else.
Identify all downstream consumers of Airplane task outputs and triage by business impact
Not all broken automations are equal. Customer-facing reports and data-integrity tasks get fixed first; internal monitoring scripts can wait.
Frequently asked questions
Is Airplane.dev shutting down or is it already shut down?
Airplane.dev is already shut down. Airtable announced the acquihire on Jan 3, 2024. The product was sunset on March 1, 2024 — all accounts were disabled and prepaid contracts were refunded. As of July 2026, the platform has been dead for over 27 months.
Can I export my Airplane.dev code?
No — not from the platform. Accounts are disabled and there is no export window. Your only recovery path is: (1) Git-backed scripts if your team pushed Airplane task code to a repository independently, or (2) browser-cached IDE sessions if you worked in the Airplane web editor. Check github.com/acode/cli if you used the CLI tool.
What happens to users and passwords from Airplane.dev?
Airplane managed auth internally. User lists and permissions are unrecoverable from the platform. Re-gather your user list from your company directory or from the access-control records of the databases and APIs that Airplane connected to. All access control must be rebuilt from scratch.
How long does an Airplane.dev rebuild take?
Typically 8–12 weeks, depending on how much code was Git-backed and how many Runbooks existed. The forensic archaeology phase (auditing connected databases, interviewing teams, checking Git history) takes 1–2 weeks before any code is written. Teams with clean Git backups and limited scope can move faster.
What should I use instead of Airplane.dev?
The options the Airplane CEO named at shutdown: Windmill (OSS, Apache 2.0 — best for developer-heavy teams who want self-hosting) and Retool (note: self-hosting moved to Enterprise-only as of early 2026; Retool Cloud remains available). For teams building product-integrated tooling, a custom Next.js admin stack with Supabase is the most flexible long-term choice.
How do I find which Airplane webhook URLs were in use?
Run a grep across your entire codebase, CI configuration, and documentation: search for 'airplane.dev', 'airplane.so', and any known task or runbook IDs. Then check every external service (Slack, GitHub Apps, Stripe, Airtable) for webhook configurations pointing at Airplane URLs. These dead URLs are causing silent failures in your production integrations right now.
How much does an Airplane.dev rebuild cost?
If you recovered clean code from Git and the scope is limited to a few Tasks, a developer can port these to Vercel Functions in 1–2 weeks. For teams with complex Runbooks, unknown scope, or live broken dependencies: freelancer work runs $3K–$10K; a fixed-price agency engagement runs $13K–$25K over 8–12 weeks. RapidDev offers a free scoping call to assess what was lost and what must be rebuilt at rapidevelopers.com.
What if I just discovered Airplane.dev references in a codebase I inherited?
Start with the forensic checklist: search Git history for task scripts, audit connected databases for Airplane-written tables, and check every external service for dead webhook URLs. Your immediate priority is identifying which Airplane-scheduled tasks fed live downstream systems — those are the broken dependencies causing the most damage right now.
We migrate no-code apps to production code
- Fixed price — $13K–$25K (agency, fixed)
- No data loss, no downtime
- You own 100% of the code
30-min call. Quote within 48 hours.