There's a certain irony in the fact that this very blog post — the one you're reading right now — is served by Apilane. The posts, the view counts, everything. It felt wrong to write about it any other way.

What is Apilane?

Apilane is an open-source backend platform that handles the parts of a web or mobile application nobody enjoys building: data management, user authentication, file storage, role-based access control, and more. The idea is simple — you define your data model through a web portal, and Apilane gives you a fully functional REST API, instantly. No boilerplate, no scaffolding, no hand-rolling auth flows.

It runs as two services: a Portal (the management UI) and an API (the actual HTTP server your apps talk to). Both can be spun up with a single docker-compose command.

docker-compose -p apilane up -d

That's it. You're up. Navigate to http://localhost:5000, log in, and start building your data model.

How it works

The core concept is the Application — a self-contained backend that holds your entities (tables), your users, your security rules, and your storage configuration. You can run as many applications as you want from a single Apilane installation, each isolated from the others.

Define an entity called Products, give it properties like Name (String), Price (Number), InStock (Boolean). Hit save. You now have a full CRUD API for that entity, with filtering, sorting, and paging already baked in:

GET /api/Data/Get?entity=Products&pageIndex=1&pageSize=20&filter=[{"property":"InStock","operator":"eq","value":true}]
x-application-token: {appToken}

Authentication is not something you configure — it's already there. Users can register, log in, confirm their email, reset their password, and manage tokens out of the box. Every authenticated request uses a token passed via the Authorization header.

File storage works the same way: upload, download, and control access. Need custom SQL logic? Define a Custom Endpoint, write parameterized SQL, and it becomes a REST API endpoint automatically.

Security that doesn't get in your way

Access control in Apilane is granular without being painful. You have two built-in roles — ANONYMOUS and AUTHENTICATED — and you can define as many custom ones as you need. Security rules can be set at the entity level, the property level, and the custom endpoint level.

That means you can allow anonymous users to read a Products entity, allow authenticated users to create records, and restrict the Cost property entirely to admins — all configured from the Portal, no code changes required.

On top of that: IP allow/block lists, sliding window rate limiting, and data encryption for sensitive fields.

The multi-tenant trick

One feature worth calling out specifically is the Differentiation Entity — Apilane's built-in approach to multi-tenancy. When you create an application, you can optionally declare a differentiation entity (e.g., Company). From that point on, every entity you mark as differentiated automatically scopes its data to the current user's company. Apilane appends the filter on every API call — no logic required on your side.

User A belongs to Company 1. User B belongs to Company 2. When User A queries Orders, they only see Company 1's orders. This is enforced at the platform level, not at the application level. It can't be bypassed.

Storage flexibility

Apilane supports SQLite, SQL Server, and MySQL as storage providers. Each application picks its own. SQLite is perfectly reasonable for smaller apps or internal tools. SQL Server and MySQL cover production workloads. The connection string is application-scoped, so you can mix providers across applications if the situation calls for it.

The .NET SDK

If you're working in .NET, there's a first-party SDK with a builder pattern that wraps all API operations:

var response = await _apilaneService.GetDataTotalAsync<Post>(
    DataGetListRequest.New("Post")
        .WithAuthToken(authToken)
        .WithPageIndex(1)
        .WithPageSize(100)
);

Type-safe, discoverable, and consistent. This is exactly how this blog fetches its posts — the PostService uses the SDK directly against an Apilane instance, with no database driver in sight.

Why bother?

The honest answer is that most backend work for CRUD-heavy apps is repetitive. You write the same auth boilerplate, the same entity controllers, the same role-checking middleware — over and over, project after project. Apilane compresses all of that into a Portal UI and a REST API that works immediately.

It's not trying to replace a complex domain-specific backend. If your application has serious business logic that lives in code, Apilane isn't the right fit for that logic. But if you need data management, users, file storage, and access control — and you want them working before lunch — Apilane is worth a look.

The fact that it's self-hosted, open-source, and built for scalability from the ground up makes it something you can actually trust to run in production.

Check out the documentation and spin one up. The docker-compose is one command. 🚀