unsubbed.co

IronCalc

IronCalc gives you modern in-browser spreadsheet engine on your own infrastructure.

Open-source spreadsheet infrastructure, honestly reviewed. Not a Google Sheets clone — something more specific and more interesting.

TL;DR

  • What it is: Open-source (MIT/Apache 2.0) spreadsheet engine built in Rust — designed to be embedded in other applications, run headless on a server, or used as a standalone self-hosted spreadsheet [README][homepage].
  • Who it’s for: Developers who want spreadsheet logic inside their own SaaS without paying for commercial components. Also teams and founders who want a self-hosted, privacy-respecting spreadsheet alternative without Google or Microsoft in the chain [homepage].
  • Cost savings: Microsoft 365 runs $6–22/user/month depending on tier. Google Workspace is $6–18/user/month. Commercial spreadsheet components like SpreadJS can run $999+/developer/year. IronCalc is $0, MIT-licensed, no per-seat fees, no vendor [homepage][README].
  • Key strength: Dual MIT/Apache 2.0 license — genuinely permissive, no commercial-use restrictions — plus a Rust core that compiles to WebAssembly, so the engine runs in a browser with no server round-trips for calculations [homepage][README].
  • Key weakness: Pre-1.0, actively in development. No real-time collaboration yet. No charts. The project itself says “not yet” to the question of whether it can replace Excel [homepage FAQ]. If you need a ready production spreadsheet product for non-technical end users today, this isn’t it.

What is IronCalc

IronCalc is a spreadsheet engine, not a spreadsheet application. The distinction matters. When most people hear “spreadsheet,” they picture Google Sheets — a multi-user cloud app where you log in, share a link, and your colleague sees your cursor move in real time. IronCalc is the layer underneath that: the thing that parses =VLOOKUP(A1, B:C, 2, FALSE), evaluates it against a data model, and returns the result [README][homepage].

What you do with that engine is up to you. The project ships several “skins”: a browser-based web app available at https://app.ironcalc.com as an early preview, a planned terminal UI, and planned desktop application. But the primary value proposition — and the thing that distinguishes it from every other open-source spreadsheet attempt — is the embeddable engine: a Rust crate you pull into your application, Python bindings, JavaScript/WASM bindings for browser use, and a Node.js binding [README][homepage].

The engine compiles to WebAssembly, which means calculations happen inside the browser with no server round-trip. You load a 10,000-row model and recalculate it; every formula evaluates locally at near-native speed [homepage]. The same Rust core that runs in the browser can run on your server for headless batch computation [homepage FAQ].

The project is run by IronCalc GmbH and has received funding from the European Commission’s Horizon Europe programme (via the ELFA Consortium) and the NLnet Foundation’s NGI0 Core Fund [homepage]. That’s an unusual backing structure for a spreadsheet tool — it signals that the project is oriented toward open infrastructure rather than a VC growth story. As of this writing it sits at 3,834 GitHub stars and describes itself as still in the “very stages of the project” [README].


Why people choose it

Third-party reviews of IronCalc specifically are sparse — the project is young and pre-1.0, so the usual wave of “top 10 self-hosted spreadsheets” listicles hasn’t caught up yet. What we have is the primary source material: the README, website, and FAQ, which are unusually candid.

The honest pitch, taken directly from the FAQ: “Can IronCalc replace Excel? Not yet.” That’s a more useful starting point than most open-source projects offer [homepage FAQ].

The case for IronCalc breaks into three distinct audiences, each with a different motivation:

Developers building SaaS with spreadsheet logic. Commercial components like SpreadJS or Handsontable exist for embedding spreadsheet UI into web applications, but they’re either proprietary, expensive, or both. IronCalc’s MIT/Apache 2.0 dual license means you can embed it in a commercial product, ship it to clients, or fork it without a commercial agreement [README]. This is the strongest argument: there is no other serious Rust-native, WASM-capable, genuinely open-source spreadsheet engine at this level of completeness.

Founders and small teams escaping Google Workspace bills. Google Sheets is “free” until you’re a business, at which point Google Workspace starts at $6/user/month. For a 10-person company that’s $720/year for a suite where spreadsheets are your most-used feature. IronCalc self-hosted on a $5 VPS is $60/year [homepage]. The practical gap is real-time collaboration, which IronCalc doesn’t have yet [homepage FAQ].

Privacy-focused teams handling sensitive data. The FAQ notes that spreadsheets stored in the web app live in browser storage unless you add server-side storage yourself [homepage FAQ]. For teams running their own instance, that means formulas and data never touch Google or Microsoft servers — the entire calculation pipeline is local.


Features

Spreadsheet engine:

  • 300+ supported functions including standard Excel-compatible formulas [homepage]
  • Dynamic arrays [homepage]
  • Named ranges [homepage]
  • Multiple sheets [homepage]
  • Conditional formatting [homepage]
  • Custom number formats [homepage]

Import / Export:

  • .xlsx import and export — formulas and data preserved [homepage][README]
  • The README example shows a Rust program that builds a 100×100 grid, adds a cross-sheet SUM formula, evaluates it, and writes a valid .xlsx file in ~15 lines of code [README]

Formatting and UX:

  • Rich text formatting [homepage]
  • Frozen rows and columns [homepage]
  • Image upload [homepage]
  • Hide rows and columns [homepage]
  • Autofill [homepage]
  • Templates [homepage]

Language bindings:

  • Rust crate (primary) [README]
  • JavaScript / WebAssembly [README][homepage]
  • Python bindings [homepage]
  • Node.js [README]

Deployment:

  • Docker Compose: docker compose up --build, then http://localhost:2080 [README]
  • REST API available [merged profile]
  • Runs entirely in browser via WASM — no server needed for calculations in web embed mode [homepage]

What’s missing or in-progress:

  • Charts: explicitly listed as “not yet supported” [homepage FAQ]
  • Real-time collaboration: planned, not built [homepage FAQ]
  • The project acknowledges it’s still “evolving toward version 1.0” [homepage FAQ]

Pricing: SaaS vs self-hosted math

IronCalc has no pricing page because there’s nothing to buy. The software is dual-licensed MIT/Apache 2.0 [README]. There is no cloud SaaS tier, no enterprise license tier, no usage limits, no per-seat fees. You either run it yourself or use https://app.ironcalc.com as an early demo.

What you’re replacing:

Microsoft 365 Personal: $6.99/month (includes Excel) Microsoft 365 Business Basic: $6/user/month — Excel online, no desktop Microsoft 365 Business Standard: $12.50/user/month — desktop Excel included

For a 5-person team on Business Basic: $360/year. For Business Standard: $750/year.

Google Workspace Business Starter: $6/user/month — includes Sheets 5-person team: $360/year.

Commercial spreadsheet components (for embedding):

  • SpreadJS: starts around $999/developer/year
  • Handsontable Pro: ~$380/year for commercial use
  • IronCalc: $0, no restrictions

Self-hosted math:

  • IronCalc software: $0
  • VPS to run the Docker container: $5–10/month (Hetzner, Contabo, Vultr)
  • Total per year: $60–120 + your time

For a solo founder who just wants a private spreadsheet not connected to Google: the math is obvious. For a developer embedding spreadsheet functionality into a SaaS product and avoiding a $999/year commercial component license: also obvious.

The caveat worth stating clearly: if you’re replacing Google Sheets as a day-to-day collaborative tool for a non-technical team, IronCalc isn’t ready yet. The collaboration features aren’t built. You’d be accepting a meaningful functional downgrade today in exchange for the cost and privacy benefits.


Deployment reality check

The README install path is three commands:

docker compose up --build

Navigate to http://localhost:2080. That’s the complete install guide for local use [README]. For production self-hosting you’d add a reverse proxy (Caddy or nginx), a domain, and HTTPS — standard Docker deployment plumbing.

What you actually need:

  • Docker and docker-compose on a Linux VPS
  • Minimum 1GB RAM (the engine is built in Rust with minimal dependencies — it’s not running a JVM or heavy Node.js process)
  • A reverse proxy if you want HTTPS
  • A domain if you’re hosting it for your team

What can go sideways:

  • The web app stores spreadsheets in browser storage by default. There’s no built-in persistence layer for a multi-user deployment — the FAQ is explicit about this: “In the web app, spreadsheets are typically stored locally (e.g., in browser storage) unless you build additional server-side or cloud storage into your integration.” [homepage FAQ] If you want file persistence across sessions, you’re wiring that up yourself or waiting for the roadmap.
  • No user accounts or auth system yet [homepage FAQ]. If you’re hosting this for a team, access control is handled at the network/reverse proxy level, not inside IronCalc.
  • No collaboration — two people can’t edit the same spreadsheet simultaneously [homepage FAQ]. This is the biggest practical limitation versus Google Sheets.

For a developer running IronCalc as an embedded engine in their own application — as opposed to a standalone spreadsheet tool — these limitations don’t apply. You’re calling the Rust library or Python bindings directly and managing your own persistence.

Realistic time estimate for a technical user: 15–30 minutes to a running Docker instance. For a developer integrating the Rust crate into an application: depends heavily on your use case, but the API is clean and documented at https://docs.rs/ironcalc [README]. For a non-technical founder, the Docker route is approachable following standard guides, but the lack of a polished admin UI means you’ll want someone technical to set up and maintain it.


Pros and cons

Pros

  • Genuinely dual-licensed MIT/Apache 2.0. Embed in commercial products, fork, resell, no commercial agreement needed [README]. This is rare — most “open source” spreadsheet tools have commercial-use carve-outs.
  • Rust core. Fast, memory-safe, minimal dependencies. The engine doesn’t pull in a 200MB dependency tree. WASM compilation works, which means browser-native calculations without server round-trips [homepage][README].
  • 300+ Excel-compatible functions with .xlsx import/export. The functional core is real — this isn’t a demo that handles =SUM and breaks on =INDEX/MATCH [homepage].
  • Multiple language bindings. Rust, Python, JavaScript/WASM, Node.js — you can use the same engine from whatever stack you’re on [README][homepage].
  • Backed by institutional funding. European Commission and NLnet Foundation backing means the project isn’t going to disappear because a startup runs out of runway [homepage]. Different risk profile from a solo-developer open-source project.
  • Docker deployment is genuinely simple. One command, works [README].
  • Headless calculation mode. Use the engine server-side for formula evaluation, business rules, batch processing — no browser or UI required [homepage FAQ][README].
  • Honest roadmap. The project doesn’t market itself as an Excel replacement. It says “not yet” in its own FAQ [homepage FAQ]. That honesty is a positive signal.

Cons

  • Pre-1.0, actively in development. Not production-stable for all use cases [homepage]. The README calls it “work-in-progress” [README].
  • No real-time collaboration. If you’re replacing Google Sheets for a team, this is the hard blocker. It’s on the roadmap but not built [homepage FAQ].
  • No charts. Basic spreadsheet requirement, explicitly listed as missing [homepage FAQ].
  • No built-in persistence for multi-user web deployment. Browser storage is the default. Building proper file storage requires custom integration [homepage FAQ].
  • No user accounts or access control. Network-level auth only [homepage FAQ]. Not suitable as a team tool without additional infrastructure.
  • 3,834 stars and small community. The README is candid: “We don’t have a vibrant community just yet.” [README] Fewer community integrations, fewer answered Stack Overflow questions, smaller pool of people who’ve hit your specific edge case.
  • Limited third-party validation. No major review coverage yet. You’re betting on the project’s own documentation and a relatively small production deployment base.
  • Not a spreadsheet product for non-technical users. The web app at https://app.ironcalc.com is an early preview. The primary value is the embeddable engine, which requires technical integration.

Who should use this / who shouldn’t

Use IronCalc if:

  • You’re building a SaaS product that needs embedded spreadsheet functionality and you don’t want to pay $999+/year for a commercial component license.
  • You need headless formula evaluation — running Excel-like calculations on a server, in a CLI, or as part of a data pipeline.
  • You want a self-hosted spreadsheet for personal or small-team use and collaboration isn’t a requirement.
  • You need MIT/Apache 2.0 licensing specifically — you can redistribute, embed in a commercial product, or fork without restrictions.
  • You’re a Rust developer looking for a well-maintained Rust crate for spreadsheet logic.
  • Privacy matters more than features: you want formulas and data to stay inside your own infrastructure.

Skip it (use Google Sheets or Microsoft 365) if:

  • Your team collaborates on spreadsheets in real time. Collaboration isn’t built yet [homepage FAQ].
  • You need charts. They’re not there [homepage FAQ].
  • You need non-technical team members to use it without setup help. The web app is a preview, not a polished product.
  • You need guaranteed production stability today. Pre-1.0 means the API can change.

Skip it (use Grist) if:

  • You want a self-hosted spreadsheet-database hybrid with real collaboration and user management. Grist is further along as a user-facing product while remaining open source.

Skip it (use Ethercalc) if:

  • You need collaborative real-time editing specifically and can accept an older, simpler interface.

Skip it (use Handsontable or SpreadJS) if:

  • You need an enterprise-grade, commercially supported spreadsheet component with extensive UI customization and paid support contracts, and the license cost is acceptable.

Alternatives worth considering

  • Google Sheets — the obvious incumbent. Free for personal, $6+/user/month for teams. Real-time collaboration, charts, 500+ functions, mature. Zero privacy, Google owns your data.
  • Grist — open-source (Apache 2.0), self-hostable, spreadsheet-database hybrid. Has real collaboration, user accounts, and access control. More mature as a user-facing product than IronCalc. Less suitable as an embeddable engine.
  • Ethercalc — older self-hosted collaborative spreadsheet. Real-time sync via CRDT, but the project is in maintenance mode and the interface hasn’t aged well. Consider only if you need collaboration right now.
  • Luckysheet — open-source (MIT) browser-based spreadsheet with collaboration. JavaScript-based, active development, more UI-complete than IronCalc’s web app. Weaker on the embeddable engine story.
  • LibreOffice Calc — the desktop alternative. Full Excel compatibility, free, no cloud dependency. Not embeddable as a web component, not self-hosted as a service.
  • Handsontable — commercial/open-source spreadsheet component for web embedding. MIT for open-source projects, paid for commercial use. More mature UI component than IronCalc today, but proprietary for commercial embedding.

For a developer evaluating embeddable spreadsheet engines specifically, the realistic shortlist is IronCalc vs Handsontable/SpreadJS. Pick IronCalc if the MIT license and Rust performance matter and you can accept pre-1.0 status. Pick a commercial option if you need support contracts and production stability guarantees today.

For a founder wanting a self-hosted team spreadsheet, the realistic shortlist is IronCalc vs Grist. Pick Grist if you need collaboration and user management now. Pick IronCalc if collaboration isn’t a requirement and you want the simplest possible self-hosted option.


Bottom line

IronCalc is solving a specific, real problem: there is no good open-source, permissively licensed, high-performance spreadsheet engine for developers who need to embed spreadsheet logic in their applications. It’s filling that gap with a Rust core, WebAssembly compilation, and dual MIT/Apache 2.0 licensing. The trade-offs are equally specific: it’s pre-1.0, the collaboration features aren’t built, and the web UI is a preview rather than a finished product.

For a developer looking to embed spreadsheet functionality in a SaaS and avoid a four-figure annual component license, the math is immediate. For a non-technical founder wanting to escape Google Workspace bills, the honest answer is: not yet unless your team doesn’t need real-time collaboration. The project is moving, the funding is institutional rather than VC, and the license is genuinely permissive. Worth watching; worth considering today if your use case fits the current feature set.


Sources

  1. IronCalc GitHub README — Main engine of the IronCalc ecosystem. https://github.com/ironcalc/ironcalc
  2. IronCalc Official Website — Open source spreadsheet engine. https://www.ironcalc.com
  3. IronCalc Website FAQ — Feature status, roadmap, and usage guidance. https://www.ironcalc.com/#faq
  4. IronCalc Web App (Early Preview) — Browser-based preview of the engine. https://app.ironcalc.com
  5. IronCalc API Documentation (docs.rs) — Rust crate documentation. https://docs.rs/ironcalc/latest/ironcalc/

Features

Integrations & APIs

  • REST API