Skip to content

Frequently Asked Questions

MolnOS is a self-hosted, microscale cloud control plane that provides core cloud infrastructure primitives—IAM, functions, storage, databases, and observability—in a tiny ~430KB package. It’s designed to run on your own infrastructure without external dependencies or subscriptions.

How is MolnOS different from AWS/Azure/GCP?

Section titled “How is MolnOS different from AWS/Azure/GCP?”

MolnOS is intentionally microscale and self-hosted, while hyperscalers are massive managed services.

Just to highlight a few key differences:

  • Ownership: You own MolnOS with a one-time purchase; hyperscalers charge ongoing consumption-based fees
  • Scale: MolnOS scales to your hardware limits; hyperscalers scale globally
  • Complexity: MolnOS has 7 core services; AWS has 200+ services
  • Dependencies: MolnOS has none (read more below); hyperscalers require internet and accounts
  • Data location: MolnOS runs where you put it; hyperscalers run in their data centers

See the Comparison page for detailed analysis.

No, MolnOS is proprietary commercial software. Modification and redistribution are restricted.

Yes, for personal projects, learning, and educational purposes. Commercial or organizational use requires a paid license. See Licenses for details.

Microscale means MolnOS is intentionally small and simple rather than trying to be everything for everyone. The entire platform is ~430KB, runs as a small number of processes, and provides focused core primitives instead of hundreds of specialized services.

What do you mean with “no dependencies”?

Section titled “What do you mean with “no dependencies”?”

“No dependencies” means that, in terms of external packages, the full supply chain of bundled/compiled and distributed code is entirely controlled by one individual: Mikael Vesavuori, who is also the creator of MolnOS. This keeps the codebase efficient and extremely small.

As for runtime dependencies, you decide how many—and which ones—you put in play. If you want passwordless login (emails) for sign-in, you’ll likely be using an external SMTP provider. And for OAuth sign-in, you can easily choose common providers like Google or Microsoft. But both options do give you the freedom to roll your own and connect MolnOS to your own options, such as using self-hosted Keycloak for logins.

It’s always possible to go overboard and be a fundamentalist, but functionally you can almost not be less coupled to any provider or technology as with MolnOS. Certainly not in the cloud space!

Minimum:

  • Operating System: macOS or Linux
  • Runtime: Node.js 24 or later
  • CPU: Single core (ARM or x86)
  • RAM: 256MB available
  • Storage: 100MB + room enough to have Node.js installed

Recommended:

  • CPU: 2+ cores
  • RAM: 512MB+
  • Storage: 1GB+ for databases, logs, and objects

Yes! MolnOS runs on Raspberry Pi (including Raspberry Pi Zero) and other ARM devices. This makes it viable for edge computing and IoT scenarios where traditional cloud platforms don’t reach.

Yes, MolnOS operates fully offline after installation. Everything—functions, storage, databases, IAM, etc.—works without internet connectivity.

Yes, though it’s not required. MolnOS is just a Node.js application, so you can containerize it if desired. However, one of MolnOS’s benefits is that it doesn’t require Docker or container orchestration—it runs directly on the host system.

MolnOS includes an embedded key-value database built on PikoDB. It’s optimized for fast operations with support for TTL (time-to-live) and dictionary grouping. It’s not a relational database—if you need SQL, consider using MolnOS alongside PostgreSQL or integrating with external databases via functions.

What programming languages can I use for functions?

Section titled “What programming languages can I use for functions?”

Functions are written in JavaScript/Node.js. The function runtime executes in the same Node.js environment as MolnOS itself, providing access to the full Node.js ecosystem and npm packages.

Yes, MolnOS is production-ready for workloads that fit its design constraints (single-host deployment, vertical scaling, JavaScript functions). However, it doesn’t include built-in high availability or automatic failover. For mission-critical systems, implement appropriate backup, monitoring, and disaster recovery strategies.

Since version 1.0.3, the easiest way is via npm on macOS or Linux with Node.js 24+:

Terminal window
npm install -g molnos

Alternatively, you can use the CLI installer which includes additional CLI tooling:

Terminal window
curl -sSL https://releases.molnos.cloud/install.sh | bash

See the Installation Quickstart for details.

Yes, you can run multiple independent MolnOS instances. Each instance has its own data and operates independently—there’s no automatic data synchronization. Use multiple instances for tenant isolation, different environments (dev/staging/prod), or geographic distribution.

Back up the MolnOS data directory, which contains:

  • PikoDB database files
  • Object storage files
  • Log files
  • Configuration

The entire state of your MolnOS installation is in this directory. Regular filesystem backups are sufficient.

Just run molnos upgrade to update the CLI and Core.

You can run multiple MolnOS instances behind a load balancer, but each instance is independent. MolnOS is designed for vertical scaling (adding resources to a single host) rather than horizontal clustering with automatic data replication.

For true horizontal scaling with shared state, you’ll need to implement application-level data synchronization or use MolnOS for stateless workloads with external data stores.

MolnOS includes built-in observability with centralized logging. You can:

  • Query logs via the API or web console
  • Export logs to external systems
  • Monitor via a health check endpoint

MolnOS doesn’t include built-in HA or clustering. For high availability:

  • Run multiple independent instances behind a load balancer
  • Implement your own data replication
  • Use external monitoring and automated failover

MolnOS includes comprehensive security features:

  • Role-based access control (RBAC) with fine-grained permissions
  • Flexible authentication: passwordless email signin (magic links) or OAuth (Google, GitHub, self-hosted providers)
  • API key authentication for service accounts
  • Isolation boundaries between users, functions, and services
  • CSRF protection, rate limiting, and HTTPS enforcement for OAuth flows
  • Security headers (CSP, HSTS, X-Frame-Options)

As with any self-hosted software, security depends on proper configuration, network security, and operational practices.

No. MolnOS makes no telemetry or usage tracking calls. All data and operations remain within your infrastructure.

Can MolnOS run in air-gapped environments?

Section titled “Can MolnOS run in air-gapped environments?”

Yes. After installation, MolnOS operates completely offline.

MolnOS itself is self-hosted infrastructure software. Compliance depends on how you deploy and operate it. Because you control where data lives and who accesses it, MolnOS can be part of a compliant architecture—but compliance is your responsibility, not inherited from a vendor.

Your data is stored exactly where you install MolnOS—on your server, VM, edge device, or wherever you run it. Data never leaves your infrastructure unless you explicitly send it somewhere via functions or integrations.

You need a commercial license ($499 one-time) if you use MolnOS:

  • For commercial purposes
  • Within any organization (business, non-profit, government)
  • To provide services to customers
  • In any commercial context

Personal projects, learning, and educational use are free. See How Licenses Work for details.

A single license includes:

  • Perpetual use rights (own it forever) for a single major version (e.g. version 1.x)
  • Unlimited deployments
  • Unlimited users
  • Future updates for the major version that the license is valid for
  • Commercial usage rights

Can I use one license for multiple deployments?

Section titled “Can I use one license for multiple deployments?”

Yes. A single license covers unlimited deployments within your organization. Run as many instances as you need on as many hosts as you need.

Section titled “What if my organization has multiple legal entities?”

Each separate legal entity (e.g. subsidiaries or related companies) requires its own license.

Due to the nature of software licenses, all sales are final. However, you can use MolnOS for free for personal/educational purposes to evaluate it before purchasing a commercial license.

The license includes dedicated email support for a year after purchase. Community support is also available via GitHub Discussions.

See Use Cases for example use-case scenarios or the Comparison page for detailed analysis.

Absolutely. MolnOS works well in hybrid architectures:

  • Use MolnOS for sensitive data on-premises + cloud CDN for public assets
  • Combine MolnOS primitives with containerized applications on Coolify
  • Develop locally on MolnOS -> deploy to cloud PaaS for production
  • Run MolnOS at the edge with central cloud for aggregation

MolnOS’s standard HTTP APIs make integration straightforward.

MolnOS won’t start. What should I check?

Section titled “MolnOS won’t start. What should I check?”

Common issues:

  1. Node.js version: Ensure Node.js 24 or later is installed (node --version)
  2. Port conflicts: Check if the configured port is already in use
  3. Permissions: Ensure write permissions for the data directory
  4. Disk space: Verify sufficient storage available
  5. Logs: Check system and MolnOS logs for specific error messages

See Troubleshooting for detailed guidance.

  • Documentation: Check this documentation site first
  • GitHub Discussions: Community support and discussion
  • General questions: [email protected] for e.g. licensing and commercial inquiries
  • Email support: [email protected] for paying customers

Yes! Feature requests are welcome via GitHub Discussions. There will be priority to features that align with MolnOS’s design philosophy of simplicity, portability, and self-containment. Paying customers’s requests get priority, where relevant.

If your question isn’t answered here: