Introduction
A Node.js SaaS app can run without an API gateway during the prototype stage. It can expose Express routes, validate JWTs in middleware, and use a small Redis-backed limiter to protect login endpoints. That architecture becomes fragile once customers start integrating with your API directly, traffic grows across regions, and pricing plans depend on request quotas.
At that point, API gateway and rate limiting decisions become business infrastructure. The right stack can protect your origin servers, enforce fair usage, separate customer tiers, publish developer-facing APIs, route traffic across services, and give engineering teams a cleaner place to apply auth, caching, analytics, and abuse controls.
The hard part is that “API gateway” means different things depending on the product. Kong and Tyk are full API management platforms. Zuplo is a developer-first managed gateway. AWS API Gateway is deeply integrated with AWS serverless workloads. Cloudflare rate limiting protects APIs at the edge. Express middleware and Redis-based libraries solve a narrower but still important problem inside the Node.js application.
This guide compares these options from the perspective of a production Node.js SaaS team: what each option is good at, where pricing can become complex, and how to decide when middleware is enough versus when a real API gateway is justified.
Quick Comparison Table
| Option | Best For | Deployment Model | Rate Limiting Style | Cost Profile | Main Trade-off |
|---|---|---|---|---|---|
| Zuplo | Developer-first SaaS APIs, API keys, customer-plan limits | Managed gateway | Policy-based, can limit by IP, user ID, API key, or custom attributes | Free/paid managed plans; confirm before publishing | Less infrastructure control than self-hosting |
| Kong Gateway / Konnect | Enterprise API management, hybrid cloud, plugin ecosystem | Managed, hybrid, dedicated, or self-hosted depending on plan | Plugin-based, with local, cluster, and Redis strategies | Can become request- and plan-dependent; confirm before publishing | Operational and pricing complexity |
| Tyk | Open-source and enterprise API management | Self-hosted or managed options | API-level and key-level limits | Open-source entry path plus paid options; confirm before publishing | Requires gateway operations knowledge |
| AWS API Gateway | AWS serverless Node.js APIs, Lambda integrations, AWS-native auth | Fully managed AWS service | Throttling, usage plans, API keys, WAF integration depending on API type | Pay per API call and data transfer; free tier for new accounts | Can become expensive at high volume or with REST APIs |
| Cloudflare Rate Limiting | Edge protection, login/API abuse prevention, origin cost control | Edge/WAF layer | Rule-based limits using request matching expressions | Plan-dependent; confirm before publishing | Not a full SaaS API management platform by itself |
| express-rate-limit | Small Express apps, login/password reset endpoints | In-app middleware | Basic Express middleware limits | Very low direct cost | Limited cross-service and edge protection |
| rate-limiter-flexible + Redis | Distributed in-app limits, custom tenant logic | In-app library with shared store | Redis-backed counters and custom logic | Requires Redis hosting and app maintenance | You own correctness, operations, and observability |
What an API Gateway Should Do for a Node.js SaaS App
For a SaaS product, the gateway is not just a reverse proxy. It is the traffic control layer between customers, integrations, internal services, and your Node.js application. A good gateway strategy should answer four questions.
First, who is making the request? This may involve API keys, OAuth tokens, JWTs, mTLS, or signed webhook calls.
Second, how much traffic is that actor allowed to send? Rate limits may be based on IP, user ID, organization ID, API key, subscription plan, endpoint, region, or a custom bucket.
Third, what happens when the limit is exceeded? Your system should return a standard 429 response, clear rate-limit headers, and useful retry behavior.
Fourth, where should the decision happen? Some limits belong at the edge. Others require application state and should live closer to the Node.js service.
A common mistake is to put every rule inside Express middleware. That works when the app is small, but it lets abusive traffic reach your runtime, database connection pool, and logging pipeline before being rejected. Another mistake is to move every rule to a gateway before the product has stable API packaging. That can add unnecessary complexity when the only requirement is protecting a login route.
The practical answer is usually layered. Use edge or gateway limits for abuse prevention and gross traffic caps. Use application-level limits for tenant-aware business rules that require SaaS plan context.
Managed Developer-First Gateways
Zuplo
Zuplo is one of the more relevant managed options for small and mid-sized Node.js SaaS teams because it is built around developer workflows rather than heavy enterprise gateway operations. Its rate-limit policy can limit requests by IP address, user ID, API key, or custom attributes. Zuplo’s documentation also describes use cases such as customer-tier limits, quota management, and returning 429 responses with appropriate headers.
That makes Zuplo a strong fit when your SaaS exposes APIs to customers and you want a managed layer for API keys, docs, developer portal workflows, and plan-based request controls. It is also easier to adopt than a self-hosted gateway if your team does not want to operate gateway clusters, Redis-backed gateway counters, or multi-region control planes.
Zuplo’s pricing page currently describes a real free tier and a Builder plan with a flat monthly price plus transparent per-request add-ons, but pricing can change quickly, so confirm before publishing. The important editorial angle is not just “Zuplo is cheaper” or “Zuplo is simpler.” The more useful distinction is that Zuplo fits teams that want API product features without committing to a large APIM platform.
Choose a managed developer-first gateway when you need API keys, customer-facing API docs, usage analytics, plan-based limits, and fast iteration. Avoid it if your company already standardizes on Kubernetes ingress, service mesh, or an enterprise gateway platform.
Enterprise and Self-Hosted Gateways
Kong Gateway
Kong Gateway is one of the best-known API gateway options for teams that need a mature plugin ecosystem, hybrid deployment models, and enterprise API management. Kong’s rate-limiting plugin can limit HTTP requests over periods such as seconds, minutes, hours, days, months, or years. Its documentation also describes local, cluster, and Redis strategies, while the advanced rate-limiting plugin adds multiple limits, sliding or fixed windows, and Redis Sentinel or Redis Cluster support.
For Node.js SaaS apps, Kong makes sense when API gateway behavior is a platform concern rather than a single app concern. Examples include multiple backend services, multiple protocols, hybrid cloud, enterprise security requirements, centralized governance, and a platform team that can manage gateway configuration safely.
The cost side needs careful review. Kong’s pricing page currently separates Plus and Enterprise plans and references gateway limits, included request volumes, additional request costs, and custom pricing for larger organizations. Exact numbers and packaging should be confirmed before publishing because enterprise gateway pricing frequently changes and often depends on request volume, support, deployment model, and add-ons.
Tyk
Tyk is another strong API management option, especially for teams that want an open-source gateway path. Tyk documentation describes rate limiting as a way to control how clients consume APIs, including API-level limits and key-level limits. It can fit teams that want open-source control but still need API management features beyond a simple Express middleware.
Self-hosted gateways are not automatically cheaper. They move cost from vendor invoices into operations: deployment, upgrades, Redis or storage dependencies, alerting, backups, multi-region behavior, and incident response. They are most attractive when you need control, compliance, custom networking, or high request volume where managed request pricing becomes expensive.
Cloud Provider Gateways and Edge Rate Limiting
AWS API Gateway
AWS API Gateway is a natural option for Node.js SaaS apps already built on Lambda, ECS, IAM, CloudWatch, and AWS-native networking. AWS pricing states that for HTTP APIs and REST APIs you pay for API calls received and data transfer out, with no minimum fees or upfront commitments. AWS also lists a free tier for new customers that includes one million REST API calls, one million HTTP API calls, one million WebSocket messages, and 750,000 connection minutes per month for up to 12 months.
The key AWS decision is HTTP API versus REST API. AWS documentation says REST APIs support more features, while HTTP APIs are designed with minimal features so they can be offered at a lower price. REST APIs are more appropriate when you need features like API keys, per-client throttling, request validation, AWS WAF integration, or private API endpoints. HTTP APIs are better when you need a simpler, lower-cost path for common Lambda or HTTP backend integrations.
For SaaS teams, AWS API Gateway is a good fit when the app is already AWS-native and the team wants managed scaling, IAM integration, Lambda integration, and CloudWatch metrics. It is less attractive when your API platform needs to span multiple clouds or when high request volume makes per-request gateway pricing a major line item.
Cloudflare Rate Limiting
Cloudflare rate limiting is different. It is not a full SaaS API management platform by itself, but it can be highly useful at the edge. Cloudflare’s WAF rate limiting rules allow you to define rate limits for requests matching an expression and choose an action when those limits are reached. The documentation specifically mentions protecting login endpoints from brute-force attacks and capping API calls from a single client within a time window.
For many Node.js SaaS apps, Cloudflare belongs in front of everything as an abuse and cost-control layer. It can block obvious abusive traffic before it reaches your Node.js runtime, load balancer, serverless function, or managed gateway. You may still need a gateway or in-app limiter for customer-plan quotas.
Application-Level Node.js Rate Limiting
Application-level rate limiting is still useful. The question is not whether it is “real” rate limiting, but what it should be responsible for.
express-rate-limit
express-rate-limit is a basic rate-limiting middleware for Express. Its documentation describes limiting repeated requests to public APIs or endpoints such as password reset. This makes it a reasonable first layer for small apps, prototypes, admin panels, and specific endpoints where you need a quick protection mechanism.
import rateLimit from 'express-rate-limit';
const loginLimiter = rateLimit({
windowMs: 15 * 60 * 1000, // 15 minutes
max: 5, // limit each IP to 5 login attempts per window
standardHeaders: true,
legacyHeaders: false,
message: 'Too many login attempts, please try again later.',
});
app.use('/auth/login', loginLimiter);However, basic in-memory middleware is not enough for a horizontally scaled SaaS app. If you run multiple Node.js instances, each instance may have its own local counter unless you use a shared store. That can create inconsistent limits and make abuse harder to control.
rate-limiter-flexible + Redis
rate-limiter-flexible is a more advanced pattern because it can use Redis for distributed counters. Its GitHub example shows a Redis limiter consuming points by IP and returning 429 when the limit is exceeded, with the note that it works in distributed environments because limits are stored in Redis.
import { RateLimiterRedis } from 'rate-limiter-flexible';
import Redis from 'ioredis';
const redisClient = new Redis({ host: 'localhost', port: 6379 });
const rateLimiter = new RateLimiterRedis({
storeClient: redisClient,
keyPrefix: 'rl',
points: 100, // 100 requests
duration: 60, // per 60 seconds
});
async function rateLimitMiddleware(req, res, next) {
try {
const tenantId = req.headers['x-tenant-id'] as string;
await rateLimiter.consume(tenantId || req.ip, 1);
next();
} catch {
res.status(429).json({
error: 'Too Many Requests',
retryAfter: Math.ceil(Date.now() / 1000) + 60,
});
}
}For SaaS products, Redis-backed app limits are especially useful when the rule needs product context: organization ID, plan ID, API key owner, trial state, endpoint group, billing status, or AI usage budget. These rules may be easier to express in application code than in a gateway policy.
The drawback is ownership. You must implement headers, retries, logging, dashboards, bypass policies, tests, and failure behavior. You also need to decide what happens when Redis is down. Fail-open protects availability but can allow abuse. Fail-closed protects cost but can break legitimate customers.
Decision Framework by Team Size and API Business Model
Solo Founder or Small SaaS Team
Start with the simplest safe setup: Cloudflare or your hosting provider’s edge protection, plus express-rate-limit or Redis-backed rate-limiter-flexible for sensitive endpoints. This is enough for login, password reset, invitation endpoints, public forms, and early API routes.
SaaS App with Customer-Facing APIs, API Keys, and Paid Plans
Consider a managed gateway such as Zuplo. You need limits by customer, plan, route, and token, and you need analytics that are understandable outside the backend codebase. This is also the point where developer experience matters: docs, examples, key rotation, and clear 429 behavior affect customer success.
AWS-Native Serverless Product
Evaluate AWS API Gateway carefully. Use HTTP API when its feature set is enough and REST API when you need the advanced features. The cost difference can matter at scale, so do not default to REST API without a reason.
Platform Team or Enterprise SaaS Company
Evaluate Kong or Tyk. These tools are stronger when API management is shared across many services and teams. They are also better when you need hybrid deployment, self-hosting, plugin extensibility, governance, and centralized policy management.
High-Volume Public APIs
Run cost models before committing. Managed per-request pricing, analytics retention, developer portal add-ons, Redis hosting, data transfer, WAF rules, support tiers, and engineering operations can all change the result.
Cost Factors and Hidden Trade-Offs
The visible monthly plan price is rarely the full API gateway cost. You need to model at least seven cost categories:
- Request volume. Some platforms charge per request, some include a request allowance, and some charge for infrastructure you operate yourself.
- Analytics and log retention. API analytics are valuable, but high-cardinality API logs can become expensive.
- Developer portal and API product packaging. If you plan to sell API access, portal features may be worth paying for.
- Multi-region behavior. A single-region limiter is simpler than a globally consistent limiter.
- State dependency. Redis-backed limits need Redis availability and clear failure behavior.
- Support and compliance. Enterprise SSO, audit logs, RBAC, private networking, and compliance needs can push teams into higher tiers.
- Team time. A self-hosted gateway may reduce vendor spend but increase operational burden.
Do not choose an API gateway only by the lowest starting price. Choose based on where the traffic should be stopped, how limits map to your SaaS business model, and who will own the system during incidents.
Recommended Stack Patterns
Early-Stage Node.js SaaS
Use Cloudflare rate limiting for login and public endpoints, express-rate-limit for simple Express protection, and move to Redis-backed rate-limiter-flexible once you add multiple app instances. This pattern is inexpensive and easy to understand.
API-First SaaS with Paid Plans
Use a managed gateway for API keys, docs, usage analytics, and plan-based limits. Keep a Redis-backed in-app limiter for rules that require billing or tenant context. This gives you a clean public API layer without losing application-specific control.
AWS-Native Serverless SaaS
Use AWS API Gateway with Lambda or AWS service integrations. Prefer HTTP APIs when they are sufficient. Use REST APIs only when the required feature set justifies the higher complexity and potential cost. Add AWS WAF or Cloudflare in front when public abuse protection is a major concern.
Enterprise or Multi-Service SaaS Platform
Use Kong or Tyk as the gateway platform, with policies managed through CI/CD or platform tooling. Keep service-specific limits in application code only when the gateway cannot express the required business rule safely.
Conclusion
For Node.js SaaS apps, API gateway and rate limiting choices should follow the product’s maturity. Do not overbuild an enterprise gateway before the API business model is clear. Do not rely only on Express middleware once customers, integrations, and abusive traffic can affect production reliability.
A practical path is to start with edge protection and app-level limits, add Redis when you scale horizontally, adopt a managed developer-first gateway when customer-facing APIs become part of the product, and move to Kong, Tyk, or a cloud-native gateway when API management becomes a platform responsibility.
The best stack is the one that enforces the right limit at the right layer: edge for abuse, gateway for API products, and Node.js application code for tenant-aware business rules.