Workflow Automation

Windmill as a Serverless Backend: Replacing Lambda and API Gateways for Internal Tools

Oct 18, 2026 · 3 views
devopsworkflow automationserverlessbackend developmentwindmill

For years, the standard recipe for building internal tools has involved a complex web of AWS Lambda functions, API Gateway configurations, IAM policies, and S3 buckets. While powerful for public-facing applications, this infrastructure-heavy approach often feels like overkill for internal dashboards, data pipelines, or admin panels. Enter Windmill, a self-hosted (or cloud-hosted) open-source platform that transforms code into workflows, offering a streamlined alternative to the traditional serverless backend stack.

In this post, we’ll explore how Windmill can serve as a robust serverless backend for your internal tools, reducing boilerplate, simplifying deployment, and improving developer experience.

Why Move Away from Lambda + API Gateway?

The combination of AWS Lambda and API Gateway is a proven pattern, but it comes with significant overhead:

  • Configuration Complexity: Managing IAM roles, API Gateway stages, and Lambda environment variables can be error-prone and time-consuming.
  • Scattered Logic: Business logic often gets split across multiple Lambda functions, making it hard to trace the flow of data.
  • Cold Starts: While improving, Lambda cold starts can still impact the responsiveness of internal tools where users expect immediate feedback.
  • Debugging Difficulty: Debugging distributed serverless functions requires stitching together logs from multiple sources.

Windmill addresses these challenges by providing a unified environment where you can write, schedule, and orchestrate code snippets (in JavaScript/TypeScript, Python, or Bash) directly from the browser. It acts as a "backend-as-a-service" specifically tailored for internal use cases.

How Windmill Acts as a Serverless Backend

Windmill allows you to define "scripts" (code snippets) that can be exposed as HTTP endpoints, triggered by events, or scheduled. This eliminates the need for a separate API Gateway layer. Here’s how the architecture shifts:

  1. Code Snippets as Functions: Instead of deploying a Lambda, you paste your code into Windmill. It runs in an isolated sandbox.
  2. Built-in HTTP Triggers: You can instantly generate a secure URL for any script, acting as your API endpoint.
  3. Workflow Orchestration: Chain multiple scripts together to build complex logic without managing state or callbacks.

Practical Example: Building a Data Export API

Let’s build a simple internal tool that exports user data from a PostgreSQL database to a CSV file and stores it in S3. With Lambda + API Gateway, this would require:

  1. A Lambda function with a database connection pool.
  2. An API Gateway endpoint configured to trigger the Lambda.
  3. IAM permissions for S3 and RDS.
  4. Environment variables for database credentials.

With Windmill, you can achieve the same in a single script:

// Windmill Script: export_user_data.js
import { query } from "windmill-postgres";
import { uploadFile } from "windmill-s3";

// Fetch data from PostgreSQL
const users = await query(`SELECT * FROM users WHERE active = true`);

// Convert to CSV
const csvContent = "user_id,email,created_at\n" + users.map(u => 
    `${u.id},${u.email},${u.created_at}`
).join("\n");

// Upload to S3
const s3Key = `exports/users_${new Date().toISOString()}.csv`;
await uploadFile("my-internal-bucket", s3Key, csvContent);

// Return S3 URL
return {
    status: "success",
    url: `https://my-internal-bucket.s3.amazonaws.com/${s3Key}`
};

Once saved, Windmill automatically generates an HTTP POST endpoint for this script. You can now call this endpoint from your internal frontend, without setting up API Gateway or IAM roles. Windmill handles the authentication, rate limiting, and execution environment for you.

Key Benefits for Internal Tools

  • Faster Iteration: Edit code and deploy instantly. No CI/CD pipeline required for minor changes.
  • Unified Observability: All logs, traces, and execution history are in one place.
  • Cost Efficiency: For internal tools, you’re often not paying for idle Lambda capacity. Windmill’s usage-based model can be more predictable.
  • Multi-Language Support: Mix Python, JS, and Bash in the same workflow, leveraging the best tool for each task.

When to Use Windmill vs. Traditional Serverless

Windmill is ideal for:

  • Internal admin panels and dashboards
  • Data pipelines and ETL jobs
  • Rapid prototyping of backend logic
  • Automated reporting and notifications

Stick with Lambda + API Gateway for:

  • Public-facing APIs with strict SLAs
  • High-scale, high-concurrency scenarios
  • When deep integration with AWS-specific services (like DynamoDB streams) is required

Conclusion

Windmill offers a compelling alternative to the traditional serverless backend stack for internal tools. By abstracting away infrastructure concerns and providing a unified environment for code execution and orchestration, it allows developers to focus on business logic rather than plumbing. If you’re building internal tools and finding Lambda + API Gateway to be more overhead than value, it’s worth experimenting with Windmill to see how much complexity you can eliminate.

Share:
Related Posts