What is PaaS (Platform-as-a-Service)?

PaaS is a cloud model where the provider runs the platform your code deploys onto, while you still write and manage the application. In plain terms: you rent the platform, but the app is still yours. The NIST definition draws the line precisely — the provider controls servers, operating systems, and runtimes; you control the deployed application and its data.

Key takeaways

What using a PaaS looks like

The signature PaaS experience is deploying with one command and no infrastructure setup:

# The typical PaaS workflow: push code, the platform does the rest
$ git push platform main
-----> Runtime detected: Node.js
-----> Installing dependencies, building release
-----> Launching web process (2 instances)
       https://my-api.example.app deployed

What that command deploys, though, is still a full server application you wrote — routing, validation, database wiring, auth handling:

// server.js — on a PaaS, all of this is still yours to write and maintain
import express from 'express';
const app = express();

app.get('/tasks', async (req, res) => {
  const user = await authenticate(req);            // you built this
  const tasks = await db.query(                    // and this
    'SELECT * FROM tasks WHERE owner = $1 AND done = false',
    [user.id]
  );
  res.json(tasks);                                 // and this
});

app.listen(process.env.PORT);

That’s the essential PaaS trade: infrastructure disappears, but the backend application — and every security patch, dependency upgrade, and endpoint in it — remains your codebase.

The abstraction ladder

Each cloud service model answers one question: how much do you rent, and how much do you still run?

The responsibility split, layer by layer:

Specialized PaaS flavors exist for narrower jobs — integration platforms, mobile platforms, database platforms, communication platforms — but they all sit on the same rung: a managed place to run or connect the software you build.

PaaS vs. BaaS: the practical difference

BaaS is the next rung up, and the difference shows in what you don’t write. The task-list endpoint above — auth check, query, response — is replaced on a BaaS by a direct SDK call from any client, with access control enforced by the platform:

// JavaScript / Node.js — Back4app JS SDK
const query = new Parse.Query('Task');
query.equalTo('done', false);
query.descending('createdAt');
const tasks = await query.find();
console.log(`${tasks.length} open tasks`);

// Flutter / Dart — Back4app Flutter SDK
final query = QueryBuilder<ParseObject>(ParseObject('Task'))
  ..whereEqualTo('done', false)
  ..orderByDescending('createdAt');
final response = await query.query();
if (response.success) {
  print('${response.results?.length} open tasks');
}

// iOS / Swift — Back4app Swift SDK
let query = Task.query("done" == false)
  .order([.descending("createdAt")])
query.find { result in
  switch result {
  case .success(let tasks):
    print("\(tasks.count) open tasks")
  case .failure(let error):
    print(error.localizedDescription)
  }
}

// Android / Kotlin — Back4app Android SDK
val query = ParseQuery.getQuery<ParseObject>("Task")
query.whereEqualTo("done", false)
query.orderByDescending("createdAt")
query.findInBackground { tasks, e ->
  if (e == null) {
    Log.d("Tasks", "${tasks.size} open tasks")
  }
}

PaaS vs. serverless

The models are cousins, not synonyms. A PaaS app runs continuously on capacity you configure; serverless compute materializes per event, bills per invocation, and scales to zero — at the price of cold starts and execution limits. In practice the line blurs: modern platforms bolt serverless functions onto PaaS-style hosting, and a serverless architecture can serve an entire API that a PaaS would have hosted as one app. The decision hinges on traffic shape: steady load favors an always-on PaaS process; spiky or idle-heavy load favors per-invocation compute.

Common use cases

• Custom web APIs and services. A backend with logic too specific for pre-built features — pricing engines, marketplaces, internal tools — deployed without owning servers.
• Standardizing many deployments. Teams running dozens of services adopt a PaaS so every service builds, deploys, logs, and scales the same way.
• Migrating off self-managed servers. Existing server applications (especially twelve-factor apps) move to a PaaS mostly unchanged — same code, no more OS patching.
• Where BaaS replaces PaaS: standard app backends. If the backend is users + data + files + notifications, pre-built features eliminate the application layer PaaS would host — this is the common case for mobile and web products.
• Hybrid: PaaS-style custom core, BaaS for the rest. Some teams keep one custom service on a platform while user management, data APIs, and storage come from a BaaS beside it.

Should you pick PaaS or BaaS? A decision matrix

If most requirements are standard but a few are custom, that isn’t a reason to choose PaaS — a BaaS with an embedded functions runtime covers both sides with less code to own.

Limitations and trade-offs

• You still own an application. Framework upgrades, security patches in dependencies, auth bugs — a PaaS hosts your backend; it doesn’t maintain it. This is the cost BaaS removes and PaaS doesn’t.
• Vendor lock-in. Apps written against platform-specific services and deploy formats are costly to move. Mitigations: stick to open standards, containerize, prefer platforms built on open source — the same vendor lock-in caution applies up and down the ladder.
• Cost at sustained scale. Managed convenience carries a margin; large steady workloads eventually get cheaper on lower rungs of the ladder — at the price of re-hiring the ops burden.
• Reduced control. No OS access, limited network tuning, and runtime versions on the provider’s schedule. Compliance regimes that require infrastructure control may rule the model out.
• Provider dependency. Outages, pricing changes, and deprecations arrive on the provider’s timeline, not yours. Judge the provider’s track record as part of the architecture.

How Back4app bridges the PaaS-vs-BaaS gap

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. That places it one rung above PaaS: every app starts with the full backend already provisioned. The custom-logic gap that would otherwise pull you back down to a PaaS is covered by Cloud Code — serverless functions, triggers, and scheduled jobs. And because the stack is open source, the lock-in objection inverts: the same backend can be self-hosted on any infrastructure, so moving down the ladder later stays possible without a rewrite.