🇪🇺 Fixed outbound IP for Ruby on Rails

🇪🇺 Static IP for Ruby on Rails

Your Ruby on Rails app calls partner APIs that enforce IP whitelisting, but cloud deploys rotate your outbound IP. Route Net::HTTP, Faraday, and HTTParty calls through two fixed EU IPs with one HTTPS_PROXY env var.

Get Your EU Static IP See How It Works

app/controllers/api_controller.rb

# config or .env

HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443

require "net/http"

uri = URI("https://api.partner.eu/data")

resp = Net::HTTP.get(uri)

# auto-honours HTTPS_PROXY

The Problem

Rails apps deployed on cloud platforms get dynamic outbound IPs. When your app calls a partner API that enforces IP whitelisting, those rotating IPs get blocked.

Partner APIs enforce IP allowlisting

Payment providers, CRMs, and enterprise APIs require IP whitelisting. When your Rails app's cloud deployment gets a new outbound IP on every deploy, the whitelist breaks and API calls fail silently.

Cloud platforms rotate IPs

Whether you deploy Rails on Heroku, Kubernetes, AWS, Render, or Fly.io, the outbound IP changes with every deploy or scale event. You can't predict what IP your app will call from.

Dev, staging, and prod all differ

Your Rails project has multiple environments, each with its own dynamic IP. Managing separate whitelists for dev, staging, and production is a maintenance nightmare.

No native static IP in Rails

Rails itself doesn't provide a static outbound IP feature. The IP depends entirely on where you deploy it. You need an external proxy to give your app a predictable egress.

The Solution

Set one env var. All outbound calls route through your static EU IP.

Ruby's Net::HTTP, Faraday, and HTTParty all read HTTPS_PROXY from the environment automatically. Set it once and every outbound call your Rails controllers make leaves through your fixed EU IPs.

No code changes. Set HTTPS_PROXY and your existing HTTP calls work as-is.

Two fixed EU IPs with automatic failover. If one goes down, the other takes over.

TLS passthrough. The proxy never sees your traffic. API keys and payloads stay encrypted.

Implementation

Set HTTPS_PROXY and your Rails app is done. No gem changes, no initializers.

Ruby (Net::HTTP in a Rails controller)

Your existing Rails code works as-is. Ruby's Net::HTTP reads HTTPS_PROXY from the environment automatically.

# .env or environment
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
PARTNER_API_TOKEN=your_token

# app/controllers/api_controller.rb
require "net/http"

class ApiController < ApplicationController
  def sync_partner
    # Net::HTTP honours HTTPS_PROXY automatically
    uri = URI("https://api.partner.eu/data")
    req = Net::HTTP::Get.new(uri)
    req["Authorization"] = "Bearer #{ENV['PARTNER_API_TOKEN']}"

    resp = Net::HTTP.start(uri.host, uri.port,
      use_ssl: uri.scheme == "https") do |http|
      http.request(req)
    end

    render json: JSON.parse(resp.body)
  end
end

Faraday (popular Rails HTTP client)

If you use Faraday in your Rails app, it also respects HTTPS_PROXY automatically.

# Gemfile already has: gem "faraday"

# Faraday reads HTTPS_PROXY automatically
conn = Faraday.new(url: "https://api.partner.eu") do |f|
  f.headers["Authorization"] = "Bearer #{ENV['PARTNER_API_TOKEN']}"
end

resp = conn.get("/data")
render json: JSON.parse(resp.body)

Docker / Kubernetes / Heroku

Set it wherever your Rails app runs. Never paste the proxy string in plaintext.

# Docker Compose
services:
  rails:
    env_file: .env

# Kubernetes: Secret
env:
  - name: HTTPS_PROXY
    valueFrom:
      secretKeyRef:
        name: outboundgateway-proxy
        key: proxy-url

# Heroku
heroku config:set HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443

Two IPs, automatic failover

Your account comes with two static IP addresses (for example 51.xx.xx.10 and 51.xx.xx.11). Whitelist both on your partner API. If one proxy node is briefly unavailable, traffic shifts to the other.

📖 Complete Documentation: For detailed examples, error handling, and other Ruby libraries, see the Ruby SSL Proxy Guide and all other language guides.

Why Rails developers choose OutboundGateway

A pair of fixed IPs

Two addresses to whitelist, with automatic failover. No rotating cloud pool to chase.

Zero code changes

Set HTTPS_PROXY and your existing Net::HTTP, Faraday, and HTTParty calls work as-is.

EU-hosted

European data centres and a GDPR-conscious setup, giving your Rails app a predictable EU address.

Works everywhere

Docker, Kubernetes, Heroku, Render, Fly.io, AWS. One env var covers every deployment.

Encrypted end to end

TLS passthrough means the proxy can't read your traffic. API keys and payloads stay private.

Flexible plans

Starting from €19/month. Flexible plans for every scale. Cancel anytime.

Frequently asked questions

Does this require changing my Rails Gemfile or initializers?

No. You don't need to add any gems, change your initializers, or modify your controllers. Just set the HTTPS_PROXY environment variable wherever your Rails app runs (in your .env file, Docker Compose, Kubernetes Secret, or Heroku config). Ruby's Net::HTTP, Faraday, and HTTParty all read it automatically.

Does this work with Faraday and HTTParty gems?

Yes. Both Faraday and HTTParty respect the HTTPS_PROXY environment variable by default. If you use either in your Rails app for API calls, setting the env var is all you need. No additional configuration in the gem setup.

What if my Rails app runs behind Puma or Unicorn?

The proxy works at the Ruby HTTP library level, not the web server level. Whether you run Rails with Puma, Unicorn, Passenger, or WEBrick, as long as the HTTPS_PROXY environment variable is set for the process, outbound HTTP calls from your application code route through the proxy.