Platform as a service (PaaS)

NIST SP 800-145 describes PaaS as the capability to deploy consumer-created or acquired applications built with languages, libraries, services and tools supported by the provider, without managing the network, servers, operating systems or storage, but with control over the deployed applications and possibly the configuration of the hosting environment. The model took shape with Heroku (2007), Google App Engine (2008), the original Windows Azure (2010) and the open-source Cloud Foundry (2011). The twelve-factor app methodology, written at Heroku around 2011, codified the contract between application and platform: configuration in environment variables, stateless disposable processes, backing services as attached resources, logs as event streams.

Mechanically, source code is turned into a runnable artefact by buildpacks (today standardised as Cloud Native Buildpacks, a CNCF project) or by a container image supplied by the customer. The platform schedules instances, routes HTTP through its own load balancer, terminates TLS, scales horizontally on request rate or CPU and restarts crashed processes. Local file systems are ephemeral, so any state must live in a managed database, cache or object store. Managed data services (DBaaS, queues) are PaaS too, and serverless functions (AWS Lambda from 2014, Azure Functions, Google Cloud Functions) and serverless containers (Cloud Run) extend the model with scale-to-zero, per-invocation billing and cold-start latency.

The provider patches the OS and the language runtime, but only within supported runtime versions; when a runtime reaches end of support, the upgrade becomes a customer task. Everything bundled with the application remains the customer's: third-party dependencies from npm, NuGet or Maven, authentication and authorisation logic, input handling and secrets. Secrets placed in environment variables are readable by anyone with rights to read the app's configuration and leak easily through debug pages and crash dumps; references to a key vault via a managed identity are safer. Many PaaS offerings are internet-facing by default, with private endpoints and virtual-network integration as opt-in features, and an SSRF flaw can reach the platform's local identity endpoint (for example IDENTITY_ENDPOINT in Azure App Service) and obtain tokens for the app's managed identity.

The trade-offs are lock-in through proprietary runtimes and APIs, hard platform limits (request timeouts, memory caps, no custom kernel modules) and reduced audit visibility: host-level agents cannot be installed, so assurance for the lower layers comes from the provider's SOC 2 or ISO/IEC 27001 attestations. PaaS differs from IaaS in that the customer no longer owns the OS, and from SaaS in that the customer still owns the application code.