Zappa

Definition

Zappa is an open-source command-line tool that packages and deploys Python WSGI web applications, such as those built with Django or Flask, onto AWS Lambda and API Gateway so they run as serverless functions instead of on a persistently running server. It automates the packaging of a Python application and its dependencies, the creation of the necessary Lambda function and API Gateway routes, and the configuration needed to translate HTTP requests into Lambda invocations and back.

Overview

Traditional Python web frameworks assume a long-running process listening on a socket, which does not map naturally onto AWS Lambda's request-scoped, ephemeral execution model. Zappa was created to bridge that gap for existing WSGI-based applications, letting developers take a Flask or Django app largely as-is and run it on Lambda without rewriting it around a Lambda-specific handler pattern from scratch. Zappa works by wrapping an existing WSGI application in an adapter that translates incoming API Gateway event payloads into WSGI-compatible request objects, invokes the application to generate a response, and translates that response back into the format API Gateway expects. Its CLI handles packaging the application and its dependencies into a deployment artifact sized appropriately for Lambda, provisioning the Lambda function and API Gateway resources through calls to the AWS API, and managing settings across multiple named deployment stages such as development and production. Zappa differs from AWS's own SAM CLI and the Serverless Framework in that it is narrowly focused on adapting existing Python WSGI applications rather than being a general-purpose serverless deployment framework for arbitrary event sources and languages. Where SAM or Serverless Framework require a developer to structure code around discrete function handlers, Zappa's core value is minimizing changes to an existing framework-based codebase. In practice, teams use Zappa to move an existing Django or Flask application to a pay-per-invocation serverless model without a full rewrite, often to reduce idle server costs for applications with intermittent traffic, or to avoid managing EC2 instances or containers for a smaller application. Zappa also supports scheduling periodic tasks by mapping cron-like triggers to Lambda invocations of specific application functions. The adaptation layer that makes WSGI compatibility possible introduces its own overhead and edge cases, and long-lived connections, websockets, or large file uploads that assume a traditional server model can behave differently or require workarounds under Lambda's execution constraints. Cold starts, Lambda's package size limits, and API Gateway's request and response size limits are all constraints a Zappa-deployed application inherits from the underlying platform. Projects with heavier real-time or streaming requirements often outgrow Zappa's WSGI-adaptation model and move to a dedicated server, container, or a framework designed natively for asynchronous serverless event handling. Zappa's development activity has also slowed relative to AWS's own first-party tools, which is a practical consideration for teams weighing long-term maintenance against the convenience of minimal code changes today. Teams starting a brand-new serverless project, rather than migrating an existing WSGI codebase, often find that building directly against SAM CLI or the CDK avoids depending on a smaller community project for a core piece of deployment infrastructure.

Key Features

• Deploys existing Flask or Django WSGI applications to Lambda with minimal code changes
• Adapter translates API Gateway events into WSGI requests and back
• CLI packages application code and dependencies into a Lambda-ready artifact
• Manages multiple named deployment stages such as development and production
• Supports scheduling periodic tasks as Lambda invocations
• Provisions Lambda functions and API Gateway routes automatically

Use Cases

Alternatives

Frequently Asked Questions

Related in DevOps