For apps on Vercel, serverless platforms and CI
Your partner’s API wants one fixed IP to allowlist. Penduses gives your app a dedicated outbound IPv4 that stays the same on every deploy. Send them one address, route only the calls that need it, and keep shipping on Vercel. From $39 a month, in France or Germany.
Nothing migrates. The only thing that changes is which address your partner sees.
One dedicated IPv4, allocated to your service and nobody else’s. Send it to your partner.
Redeploy as often as you like. The address does not change.
Your partner allows your IP. You allow your partner’s API. Nothing else gets through.
You edit your destination list in the panel. A call to anything not on it is refused with an error, so a misconfigured request fails fast instead of leaving from another address.
Check which address the other side sees, then make the real call.
await egress.verifyIp(echoUrl)
The SDK compares the observed address with the one you expect. Then confirm the real API call in your partner’s logs.
Example addresses. The board and the responses above are illustrations, not live test results.
Create the client once. Send the calls that need the fixed IP through egress.fetch. Every other fetch keeps its current route.
import { createEgress } from '@penduses/egress';
const egress = createEgress({
endpoints: [{
host: process.env.PENDUSES_HOST,
httpPort: Number(process.env.PENDUSES_HTTP_PORT),
username: process.env.PENDUSES_USER,
password: process.env.PENDUSES_PASSWORD,
tls: true,
}],
expectedIp: process.env.PENDUSES_EXPECTED_IP,
});// Use an HTTPS IP-echo endpoint you trust.
// Add its destination to your allowlist first.
const { observedIp, ok } = await egress.verifyIp(
process.env.PENDUSES_ECHO_URL
);
console.log({ observedIp, ok });// TARGET_URL must also be on your allowlist.
const response = await egress.fetch(
process.env.TARGET_URL
);
console.log(response.status);Paste the endpoint, port, credentials and expected IP from your panel into your server-side environment. They never go to the browser.
Call an HTTPS IP-echo endpoint you trust (allowlisted first). egress.verifyIp tells you whether the other side sees your dedicated address.
Call your partner’s API with egress.fetch. Their own API authentication still applies; only the source address changes.
Vercel with Next.js is the setup we test against. Other Node.js hosts connect the same way; a few setups need a quick look before you pay.
We are the network operator, not a reseller. The people answering your email are the people running the routers.
RIPE-registered addresses we hold and announce ourselves, on servers we operate in France and Germany. No cloud NAT gateway to build, no rented pool that someone else’s traffic shares.
Your IP is allocated to your service and shared with no other customer. Redeploys do not touch it. Pro gives you two, one in each country, so your partner can allow both.
The SDK verifies our TLS certificate before it sends credentials. Through Penduses, only the destinations on your allowlist are reachable; everything else is refused.
If Penduses cannot be reached, the call returns an error. It does not fall back to a direct connection, so your partner never sees your traffic from an address they did not approve.
Per month, excl. VAT. A paid 30-day pilot with the terms written out below, not buried in a contract.
$39per month, excl. VAT
One partner API that needs one dedicated source IP.
$79per month, excl. VAT
A second connection path, for integrations your partner can allow two IPs for.
The monthly price of the plan you buy stays fixed until you cancel. Upgrade later and the then-current price of the higher plan applies.
Pilot terms: best effort, no SLA, support by email. Fair-use transfer is per month; what happens at the limit is in your pilot terms before you pay. Price protection covers your purchased plan, not usage charges or future plans. Your hosting provider may still bill its own outbound traffic.
Something else? Ask it in the pilot form.
Use it if it satisfies your partner. Platform options are usually shared by every project in a region, apply to all of your traffic, or need a NAT gateway you run and pay for. Penduses gives you one address allocated to your service only, applied just to the calls you choose, with the allowlist and the verification built in. If your platform’s option already passed your partner’s review, you do not need us.
No. Keep your deployment and send only the server-side calls that need the fixed IP through the SDK. Everything else keeps its current route. This is an application-level change, not a network switch for the whole project.
Redeploying never changes it. The address is released only when you end the service. If you ever need to migrate, we plan the allowlist update with you first.
Send the form below. We reply by email with your credentials, the allowlist setup and the pilot terms. Adding the SDK to a Next.js app is the three-step change shown above; the longest part is usually your partner updating their allowlist.
The call returns an error for your code to handle. Pro can retry eligible new connections through the second endpoint before a request is sent. In-flight requests are never replayed, and the SDK never falls back to a direct connection from another address.
Not with the HTTP(S) SDK. Those need a compatible client or WireGuard on a host you control; a database driver on Vercel will not use an HTTP proxy on its own. Tell us the client and destination and we will say whether it works before you pay.
Run egress.verifyIp against an allowlisted HTTPS IP-echo endpoint, then make a real call with your actual client and check your partner’s logs. An IP check alone does not prove that every library in your app takes the same route.
France or Germany, with your app and your partner’s location in mind. Routing through Penduses adds one network hop; measure real request times during the pilot. We do not publish a latency figure.
Starter includes 200 GB a month and Pro 1,000 GB. What happens beyond that is written in your pilot terms before you pay. Most partner API integrations use a small fraction of it.
Several of your own apps and environments can, and their usage counts toward the same limits. If you act for different customers who each need their own identity, they need separate IPs and credentials; we confirm the arrangement with you first.
Your allowlist uses IP addresses and ports, so a hostname or CDN that resolves to new addresses needs those addresses kept on the list. We review this with you at setup. It is separate from your own source IP, which stays fixed.
No. Static Egress is for outbound connections. For routed inbound and outbound IPv4 on a host you control, see Tunnel IP below.
A routed public IPv4 /32, /29 or /28 over WireGuard for a host you control. Inbound and outbound, no NAT.
Ask about Tunnel IPIPv4 blocks for hosting companies and network operators, with routing, address management and reputation monitoring handled by us.
Discuss a blockTell us where the app runs and which API it needs to reach. We reply by email with your credentials, the allowlist setup and the pilot terms. Asking costs nothing; you pay only when you start.
Prefer plain email? hello@penduses.com