I checked the price and it seems very reasonable for a dedicated IP for trading. Pricing it this way also reflects the goodwill of the people behind the service, and it makes it easy for anyone to try it out and see if it fits their needs.
I was a bit wrong about the person.
He did not like me asking his client about how he secured his user/pwd and keys. Says he already answered that himself, apparently getting insecure about questioning a clients perspective on the offering. Makes me uneasy.
Not so ethical after all 
Guys, whats a good solution for Windows VPS for our purposes. Looking to buy asap.
You can avoid the whole AWS/GCP VPS setup if your main requirement is just static IP whitelisting for broker APIs.
I’ve been using low-latency India IPs instead — much simpler and cheaper for multi-account algo setups.
Thank you @eldorado for asking this. For a neutral comparison, we would encourage users to try the other service and make their own decision based on their actual experience. At the same time, any comparison from our side would not be entirely fair if it is based only on a landing page without understanding the underlying infrastructure, architecture, and operational practices behind the platform.
We have always chosen to maintain a very high standard in security, performance, and operational reliability, even if that comes at a premium.
To give some context around our pricing: roughly ₹250/month per IP goes toward operational, infrastructure, maintenance, monitoring, and support costs. The VM itself generally costs around $6–$8/month depending on the cloud provider and configuration. We charge the VM component at cost — this is what we pay providers like DigitalOcean or Azure on behalf of the user.
That said, as a technical learning exercise, it is interesting to examine how a service similar to ipv6-proxy.in could potentially be offered at a significantly lower price, and what tradeoffs may be involved.
What increases our cost
We provide IPv4 addresses. IPv4 addresses are billed separately by cloud providers, whereas IPv6 addresses are generally free. We intentionally chose IPv4 because it works reliably across virtually all brokers, APIs, exchanges, market data providers, and third-party services without requiring special handling from the trader.
In practice, many algo traders configure proxy settings globally or through environment variables so that all outbound traffic automatically uses the proxy. However, not every request made by an algo goes only to the broker. Trading systems often communicate with Telegram, alerting services, databases, analytics APIs, or external market data providers. With IPv6-only proxy setups, some of these services may not consistently support or route IPv6 traffic correctly, which can lead to failures that are difficult to debug.
As a workaround, traders would need to selectively bypass the proxy for certain requests and carefully manage routing logic inside their applications. That adds operational overhead and complexity. IPv4-based setups avoid these issues entirely and tend to “just work” without requiring additional configuration from the trader.
We also provide WireGuard VPN access for traders who:
- do not want to modify their algos,
- use broker SDKs that do not support proxies,
- or place orders through desktop applications and tools that cannot operate over a proxy setup.
Additionally, our proxies operate over HTTPS, which means not only the API traffic but also the proxy credentials themselves are encrypted in transit. This is important when users connect from shared or untrusted networks. If proxy credentials are exposed over the network, someone else could potentially misuse the IP address associated with the trader’s account.
Running VPN services alongside HTTPS proxy infrastructure with low latency and stable performance requires reasonably provisioned systems. In practice, this means at least 1 vCPU and 1 GB RAM per deployment.
Why a VPS is fundamentally required
To provide a cloud-based static IP with authentication, some form of proxy or VPN software must run on a VM/server, and the IP address must ultimately terminate on that system either directly or through a more complex networking architecture.
So, as far as we understand — and we may be wrong here — regardless of what any platform claims, there is always a VM or server somewhere that is actually running the proxy/VPN stack, handling authentication, and routing user traffic.
In our case, each user receives a dedicated VM, typically provisioned with 1–2 vCPUs and 1–2 GB RAM, costing approximately $6–$8/month depending on the cloud provider.
From our understanding, there are only a few practical ways to reduce the price significantly below this level.
Option 1 — Using extremely low-cost infrastructure
One possibility is using very cheap VPS providers or lesser-known infrastructure vendors.
While lower-cost infrastructure can absolutely exist legitimately, it also introduces variability in reliability, network quality, uptime guarantees, abuse controls, operational maturity, and security practices. For systems involved in live trading and financial execution, we are conservative about the environments we are willing to trust.
Our preference has always been to use established cloud providers with predictable networking, mature infrastructure, and operational stability because even brief outages or instability can directly impact trading activity.
Option 2 — Sharing a single VM across many users/IPs
Another approach is attaching multiple IP addresses and multiple users to the same VM.
Technically, this can work, and many systems in the industry operate this way. However, it introduces tradeoffs that we intentionally chose to avoid.
When many users share the same VM:
- configuration changes become more frequent,
- adding/removing users or IPs can affect shared networking state,
- and a bad deployment or configuration error has the potential to impact multiple users simultaneously.
There is also the possibility of “noisy neighbour” issues, where heavy bandwidth usage from one user can affect latency or performance for others sharing the same machine.
In our architecture, once a user’s gateway is provisioned, it remains largely untouched except during upgrades or when the user explicitly performs actions such as credential resets or VPN client changes. This significantly reduces operational drift and minimizes the chances of unrelated user activity affecting existing deployments.
The result is a setup that prioritizes stability and predictability over maximum infrastructure density.
Final thoughts
We may still be missing other implementation approaches, and we remain open to learning from the industry. Healthy competition is always good for users and pushes everyone to improve.
At the same time, with infrastructure platforms, pricing alone rarely tells the full story. The more important question is not simply “why is one service expensive,” but also “how is another service able to be so inexpensive, and what architectural or operational tradeoffs make that possible?”
Our focus has always been long-term reliability, security, isolation, predictable latency, and operational stability for traders running critical systems.
A note on our platform pricing
We are actively working on a newer version of the platform where we aim to offer both IPv4 and IPv6 gateways at a more affordable price point without compromising on reliability or security.
To achieve this sustainably, we are exploring several optimizations, including:
- longer-term infrastructure commitments with cloud providers to secure significant VM pricing discounts,
- more efficient resource allocation strategies,
- usage-based pricing models for users with lighter workloads,
- and additional architectural improvements that can reduce operational overhead while maintaining isolation and performance standards.
Our goal is not simply to reduce pricing, but to do so responsibly while preserving the qualities that traders depend on.
As the platform evolves, we expect these improvements to gradually translate into better pricing flexibility for users while continuing to maintain the standards we are known for.
Ipv 4 vs ipv 6 cost differential is understandable and the infra your offering is built/working on may be premium, hence the higher cost.
Given that majority on this forum are 9:15 AM to 3:30 PM folks (small minority of commodities traders too), the static IP order routing is needed only during market hours. Therefore all the ‘dedicated’ resource that are allocated to an ID sits idle for over 16 of 24 hours a day plus fully unused for two weekend days.
Coming from a non-tech background, just wondering if there is scope to procure infra that u get from service providers only during the market hours and not entirely dedicated 24/7 which may result is input cost saving that can ultimately result in more competitive pricing for your offering
You have perfectly identified one of the core inefficiencies with always-on cloud infrastructure.
For most traders, especially those active only during market hours, paying for dedicated resources 24/7 — including nights, weekends, and holidays — does not always make sense. In many cases, the gateway sits idle for a large part of the month.
That is exactly one of the areas we are currently working on improving.
We are building mechanisms to allocate resources more efficiently during actual market usage hours and reduce costs during idle periods. We are also exploring usage-based pricing for traders with intermittent requirements, such as expiry traders, where users pay only for the time the IP is actually used.
The main challenge is reliability. If infrastructure is not reserved in advance, cloud providers do not guarantee that a VM will always be instantly available when needed. Availability depends on real-time datacenter capacity and demand.
To address this, we are working on fallback provisioning across multiple cloud providers and regions, along with faster automated deployment systems. This new system is planned to go live by July.
1 Like
ServLoci Proxy — Static IPv6 for Broker APIs Running your Dhan or Zerodha Kite algo from your own computer?
Servloci routes broker order requests through a SOCKS5 proxy and your configured dedicated static IP—without moving the entire bot to a VPS.
Dhan + Kite supported.
This is simplest and cleanest solution. Rest everything sits on your machine or app whatever. Just order routing , nothing else
#AlgoTrading #DhanHQ #KiteConnect #StaticIP
1 Like
I am using one . Familier with https proxy. So that is working.