Migration snapshot
DecliningPlatform
an Altogic
Altogic marketing site and docs remain up (July 2026), but the npm SDK (@altogic/altogic) shows no publish in approximately 3 years (last active ~2022–2023). The Altogic team launched Agnost (agnost.dev), a separate open-source Kubernetes-native backend platform — a common 'pivot away from original SaaS' signal. No explicit shutdown notice found as of July 2026; status is genuinely at-risk. Sources: npmjs.com/~altogic; agnost.dev.
Typical timeline
6–10 weeks
Typical cost
$13K–$25K (agency, fixed)
Why teams leave an Altogic
Altogic shows the pattern of a platform whose team has moved to a successor product: stale SDK, no public roadmap updates, and a new open-source project from the same founders. The risk of waiting for an official announcement is that data may become inaccessible without warning.
npm SDK stale for approximately 3 years
The @altogic/altogic npm package has not received a publish since approximately 2022–2023. A cloud BaaS platform whose client SDK receives no updates for this long is a critical signal — new features cannot be built on it and security vulnerabilities accumulate without patches.
Team pivoted to Agnost — the open-source successor
The Altogic team launched Agnost (agnost.dev), an open-source Kubernetes-native backend platform. When the founding team builds and markets a successor product, the original SaaS is typically in quiet wind-down. This is the strongest signal that Altogic's future investment is going to Agnost, not Altogic Cloud.
Data export path not clearly documented
Unlike Supabase, Appwrite, or PocketBase which provide clear migration/export guides, Altogic's data export mechanics are not clearly documented. There is no confirmed data portability guide or eject path. This means data recovery after a platform shutdown may not be possible through self-service.
Compliance posture unreliable for at-risk platform
For a platform with uncertain operational status, SOC 2, HIPAA, and GDPR posture cannot be relied upon going forward. If you process regulated data on Altogic, the compliance risk of platform uncertainty is unacceptable.
Firebase alternative positioning overcrowded — no differentiation
Supabase, Appwrite, and PocketBase have all substantially expanded since Altogic last updated competitively. The platform has not differentiated against these alternatives in years, making it harder to justify remaining on Altogic even if it continues operating.
What can you actually take with you?
Data export from Altogic is not clearly documented — do not assume a self-service eject path exists. Cloud Function source code is yours if you have local copies or can pull via CLI. Begin extraction immediately using every available API; don't wait for official guidance.
| Asset | Can you export it? | How | Notes |
|---|---|---|---|
| Data | Partial | Export mechanisms are NOT clearly documented; try every available Altogic REST API endpoint for data export; check Altogic docs for any backup/export features; contact support to request data export assistance | Do NOT assume an eject path exists — Altogic has not published a confirmed data portability mechanism; treat every API export attempt as best-effort until confirmed |
| Code | Partial | Altogic Cloud Functions were written in Node.js via Altogic CLI — use the CLI to pull all function source code to a local directory immediately; this is your code and is portable | If Altogic CLI sync was not used regularly, source code may exist only on Altogic servers; pull it now before access is lost |
| Design/UI | No | n/a — Altogic is a headless BaaS; your frontend is separate code you own entirely | Your frontend application is not at risk — only backend data, functions, and auth records need extraction |
| Logic/Workflows | Partial | Cloud Functions (Node.js via Altogic CLI) are portable code — pull via CLI immediately; platform-level features (cron, queues, realtime) are infrastructure that must be rebuilt on the target platform | Pure business logic in functions ports cleanly to Deno (Supabase Edge Functions) or Node.js (Next.js API Routes); Altogic-specific SDK calls within functions need replacement |
| Users & Auth | Partial | Auth user records export path NOT documented; try every available API to extract at minimum user email addresses; password hash export NOT documented | Treat user auth records as at-risk; extract email list as the minimum viable export; plan a full password-reset flow post-migration; do not assume password portability |
Swipe the table sideways to see the full breakdown.
Where each piece moves in code
The target stack is either Supabase (managed PostgreSQL + auth + storage + edge functions — the most mature managed option) or Agnost (the Altogic team's own open-source Kubernetes successor — architectural similarity may reduce rewrite scope); Altogic Cloud Functions port to Supabase Edge Functions or Next.js API Routes.
an Altogic
Altogic database (BaaS data store)
In code
Supabase PostgreSQL or Agnost (OSS Kubernetes-native backend)
Supabase is more mature and managed; Agnost shares mental model with Altogic and may reduce migration friction if it fits your workload
an Altogic
Altogic Cloud Functions (Node.js via CLI)
In code
Supabase Edge Functions (Deno) or Next.js API Routes (Node.js)
Node.js function code ports to Deno with minor adjustments; replace Altogic SDK calls with Supabase SDK equivalents
an Altogic
Altogic Auth (email/password, OAuth, sessions)
In code
Supabase Auth or Clerk
OAuth providers reconfigure; email/password users need a password-reset campaign; session tokens invalidate at cutover
an Altogic
Altogic Storage (file storage)
In code
Supabase Storage or S3/Cloudflare R2
Download all files from Altogic storage buckets now; map bucket structure for re-upload to target
an Altogic
Altogic Realtime (WebSocket subscriptions)
In code
Supabase Realtime channels
Supabase Realtime supports Broadcast, Presence, and database change listeners as functional equivalents
an Altogic
Altogic Cron jobs
In code
Supabase pg_cron or Vercel Cron Jobs
pg_cron runs SQL or calls functions on schedule; Vercel Cron triggers serverless functions
an Altogic
Altogic Queues (task/message queues)
In code
Supabase Edge Functions with Upstash Redis queue, or BullMQ on a small Node.js server
Upstash Redis provides a serverless-compatible queue; BullMQ on a small VPS for more complex job patterns
an Altogic
Altogic client SDK calls (@altogic/altogic)
In code
@supabase/supabase-js client (functionally similar pattern)
Altogic and Supabase client SDKs follow a similar pattern (auth, storage, realtime, database calls); each SDK call needs updating but the conceptual mapping is close
The migration roadmap
Phase 0 — urgent data extraction — is non-standard and must come before any migration planning. You need to know what is recoverable before scoping the rest of the project. Do not begin Phase 1 until Phase 0 is complete.
Phase 0: URGENT — data and code extraction
This week- Email Altogic support today asking: Is the platform actively maintained? What is the data export process? Is there a sunset timeline? Note the response time carefully.
- Use Altogic CLI to pull all Cloud Function source code to a local directory immediately
- Export all data via every available Altogic REST API endpoint; check docs for any backup or export features
- Export user list — at minimum: email addresses — via API so you can reach users in a password-reset campaign
- Download all files from Storage buckets; document bucket names and structure for re-upload to target
Watch out: If Altogic support does not respond within 5 business days, treat non-response as a shutdown signal and accelerate migration immediately
Phase 1: Audit and target selection
1 week- Inventory all data collections, auth users, storage buckets, cloud functions, cron jobs, and realtime channels
- Decide target: Supabase (mature, managed, most community support) or Agnost (same team's OSS successor, similar mental model)
- Document all Altogic SDK calls in frontend code — each one is a migration touchpoint
- Identify which Cloud Functions use Altogic-specific SDK internally vs standard Node.js logic
Phase 2: Database and schema migration
1–2 weeks- Design PostgreSQL schema based on extracted Altogic data structure
- Import data into Supabase (or Agnost) using extracted API data; validate row counts and field completeness
- Apply Supabase RLS policies to secure data access per user role
- Verify data integrity with representative sample records before proceeding
Phase 3: Function port and infrastructure rebuild
2–3 weeks- Strip Altogic SDK calls from Cloud Function code; rewrite as Supabase Edge Functions or Next.js API Routes
- Rebuild Altogic Cron jobs as Supabase pg_cron or Vercel Cron
- Replace Altogic Queues with Upstash Redis or BullMQ
- Replace Altogic Realtime subscriptions with Supabase Realtime channels in frontend code
Phase 4: Auth migration and cutover
1 week- Configure Supabase Auth with OAuth providers; test all OAuth flows
- Execute password-reset campaign: send reset emails to all users; use magic links for first login
- Update all Altogic client SDK calls in frontend to Supabase SDK equivalents
- Cutover: point frontend to new backend; monitor error rates; decommission Altogic account
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
2–4 months part-time
Fits
Developers who can write ETL scripts, have already pulled their function code via CLI, and have a small app with limited data collections and a handful of Cloud Functions
Risks
The highest risk here is data recovery — if Altogic's export APIs are limited and you can't recover all your data through self-service, a DIY approach may not succeed regardless of skill level; start Phase 0 immediately to assess what's actually recoverable
Freelancer
$3K–$8K
4–8 weeks
Fits
Teams with moderate Altogic apps (a handful of collections, under 10 Cloud Functions, basic auth) where function code has already been extracted via CLI
Risks
Altogic's undocumented export path may require creative API reverse-engineering; ensure the freelancer has experience with API-based data recovery, not just standard migrations
Agency (RapidDev)
Done-for-you$13K–$25K fixed
6–10 weeks
Fits
Teams with production Altogic apps and active users who cannot risk data loss or extended downtime; fixed price covers data extraction best-effort, function port, auth migration, and cutover with parallel-run validation
Risks
Minimal within agency scope — fixed price covers the migration; the only uncontrollable risk is if Altogic's data export APIs cannot recover all data, which is assessed during Phase 0. Free scoping call at rapidevelopers.com.
The real risks — and how to defuse them
Data may not be recoverable via self-service — no documented export path exists
Mitigation: Start data extraction immediately using every available Altogic REST API; contact support for export assistance; do not wait for an official announcement — each day of inaction is a day of increased risk
User auth records at risk — no documented password hash export path
Mitigation: Export user email list via any available API immediately; plan a full password-reset flow post-migration using magic links; communicate the transition to users before cutover
Cloud Function source code may exist only on Altogic servers if CLI sync was not used
Mitigation: Use Altogic CLI to pull all function code to a local directory now, before access is lost; if CLI is non-functional, document all function logic from memory and recreate from scratch
Unknown shutdown timeline — no announcement means no export deadline warning
Mitigation: Treat today as the deadline; the absence of an official shutdown notice does not mean the platform will remain accessible; the risk of waiting exceeds the cost of premature action
Agnost (OSS successor) may not be production-ready for all use cases
Mitigation: Evaluate Agnost at agnost.dev against your specific workload; Supabase is more mature and managed; choose based on your team's operational capacity and the feature overlap with Altogic
Support non-response signals accelerated shutdown
Mitigation: If Altogic support does not respond within 5 business days to a direct question about platform status and export options, treat it as a shutdown signal and immediately begin emergency migration
Should you actually migrate?
Migrating is a real project. Sometimes staying is the right call — here is the honest split.
Stay if
- You receive a written response from Altogic support within 5 business days confirming: the platform is actively maintained, data export mechanisms are documented and working, and there is no sunset timeline — only stay with written confirmation in hand
- You have verified independently that the npm SDK is receiving updates and the engineering team is actively fixing bugs — not just infrastructure keeping the servers running
- You are actively evaluating Agnost (agnost.dev) as your migration target and are in the process of testing it — staying on Altogic temporarily while Agnost validation is underway is acceptable, provided you have already extracted all your data as a backup
Migrate if
- The npm SDK (@altogic/altogic) has not been updated in years and you depend on it for any new feature development — a stale SDK means no new capabilities and accumulating security risk
- Altogic support is unresponsive or takes more than 5 business days to respond to a direct question about platform status — treat non-response as a shutdown signal
- Your app has active users whose data you are responsible for — the compliance and continuity risk of an uncertain-status platform is unacceptable for production workloads
- You cannot find clear documentation for exporting your data via self-service — a platform that doesn't document data portability cannot be trusted for business continuity
Our honest verdict
The evidence pattern — stale SDK, team pivot to a successor product, no public roadmap — is a clear signal that Altogic Cloud is in wind-down mode even without an official announcement. Do not wait for confirmation that may not come. Export everything you can today and migrate to Supabase or Agnost.
Do this today: pre-migration checklist
Whatever path you choose, protect yourself first. Work through this before you touch a line of code.
Email Altogic support today asking three specific questions: Is the platform actively maintained? What is the data export process? Is there a sunset timeline?
Support response time and content is itself a signal — no response within 5 business days is a shutdown indicator; a detailed, current response lets you calibrate urgency accurately
Use Altogic CLI to pull all Cloud Function source code to a local directory immediately
Your function code is your most portable asset; if CLI access is lost, source code may be unrecoverable — do this before anything else technical
Export all data via every available Altogic API endpoint and document what is and is not recoverable
Altogic has no confirmed self-service export path; your data recovery depends entirely on what the current API exposes — you need to know this today
Extract user email list via API — at minimum, every registered user's email address
Email addresses are the minimum needed to run a password-reset campaign post-migration; without them you cannot re-engage your users after cutover
Download all files from Storage buckets and map the bucket structure
Altogic Storage files are binary assets not typically accessible via data API export; download them directly while access exists and document the folder structure for re-upload
Document all Altogic SDK calls in your frontend and mobile code
Every Altogic SDK call is a migration touchpoint for the new client library; a complete list prevents missed replacements at cutover
Evaluate Agnost (agnost.dev) alongside Supabase as migration targets
Agnost is built by the Altogic team with similar architectural concepts — the migration mental model may be shorter; compare both against your actual workload before committing to a target stack
Frequently asked questions
Is Altogic shutting down?
No official shutdown announcement has been made as of July 2026. However, the signals are concerning: the npm SDK (@altogic/altogic) has not been published in approximately 3 years, and the Altogic team launched Agnost (agnost.dev), an open-source successor product. This is a 'team pivoted to successor' pattern common in startup BaaS shutdowns. We recommend acting as if shutdown could occur without advance notice.
Can I export my Altogic data?
Altogic's data export mechanisms are not clearly documented — unlike Supabase, Appwrite, or PocketBase, there is no confirmed self-service eject path. Try every available Altogic REST API endpoint for data export, check the docs for any backup features, and contact support directly to request export assistance. Do this today, not after you've decided to migrate.
Can I export my Altogic Cloud Functions?
Yes — your Cloud Function code is written in Node.js via the Altogic CLI, and it is your code. Use the Altogic CLI to pull all function source code to a local directory immediately. If Altogic CLI sync was not used regularly, the source may exist only on Altogic servers — pull it now before access is potentially lost.
How long does an Altogic migration take?
Typically 6–10 weeks with a team, assuming data recovery is successful. The unusually large variable here is Phase 0: data extraction. If Altogic's export APIs are limited, recovery time is unpredictable. Once you know what data is recoverable, the rest of the migration follows a standard BaaS pattern. Start the extraction before scoping the timeline.
What happens to my users and their passwords when I migrate from Altogic?
Altogic's password hash export path is not documented. At minimum, export every user's email address via API so you can run a password-reset campaign post-migration. All users will need to reset their passwords — plan this as a first-class user communication, not an afterthought. OAuth users (Google, GitHub) re-authorize with the new provider and don't need password resets.
Should I migrate to Supabase or Agnost?
Both are valid targets. Supabase is more mature, fully managed, has extensive documentation and community support, and offers a clear PostgreSQL-based mental model. Agnost (agnost.dev) is built by the Altogic team on Kubernetes — architectural similarity to Altogic may reduce migration scope, and if you're comfortable self-hosting Kubernetes, it could be a natural transition. Evaluate both against your team's operational capacity and specific feature needs before choosing.
What if I can't recover my Altogic data through the API?
Contact Altogic support directly and request a data export or database dump. Document every interaction and response time. If support is unresponsive for more than 5 business days, escalate to any available contact channels (social media, community forums). Consider whether a legal data portability request is appropriate given your jurisdiction (GDPR Article 20 in the EU). Treat unresponsiveness as a signal to accelerate rather than wait.
How much does an Altogic migration cost with an agency?
RapidDev offers fixed-price Altogic migrations at $13K–$25K, which covers data extraction best-effort, function port to Supabase Edge Functions, auth migration with password-reset campaign, storage migration, and cutover. The fixed price is scoped after Phase 0 (data extraction) confirms what is recoverable. Book a free scoping call at rapidevelopers.com to assess your specific situation.
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.