Sebi has mandated static ip whitelisting. Where are you getting them?
ISP will be one option, but surely we need backup ip too right, what are your options?
1 Like
ISP/laptop + AWS.
Its a bit complicated to setup, and these guys don’t have any prepaid system and no bill limits, so security is important (someone could hack and mine crypto for example - has happened). But went for it as Z uses aws. Have also improved security of all important systems with better passwords and hardware security key (yubikey)).
Also, we can operate without opening ports to internet through tunneling - ssh/remote desktop etc. So a noobie like me hopefully will be less exposed to risk due to bad configuration or similar.
btw, for some reason windows + aws is much more expensive than linux. But i prefer linux already.
I still prefer my laptop for now as i need a way to get notified on mobile if there is error but aws is ready and i use it a bit every day too.
2 Likes
Simple solution will be buy a VPN subscription with dedicated IP. you connect whatever system ( AWS or Laptop or mobile etc) to this VPN and let your software trade as usual. Brokers only see IP of your VPN. No need to change your existing trading systems. VPN is an added cost, but it is by far the simplest and reliable solution for this.
If you want to avoid setting up your own VPN, managing VMs, dealing with networking, security, and latency, you could check out something we recently released for Indian traders. It’s a fully managed trading gateway, hosted on DigitalOcean/Azure infrastructure, with a fixed Indian IP (Bangalore), VPN and secure proxy support.
It costs just ₹716 per month—much less than most alternatives—and lets you trade freely from your local device or any cloud server. One-click management, fully secure and hardened, no tech hassle.
More details here: https://www.quancradle.com. You can also email [email protected] to get up to one month free on your gateway validity.
Checkout some blogs for more details on this -
An honest take on the product.
From a latency and stability perspective, I don’t think using a gateway server to route orders which adds an additional layer in the order flow from trader’s machine to broker’s system and finally to exchange’s matching engine, will be better than getting a fixed IP from ISP.
From a cost perspective, it’s many times expensive than static IP by isp. In my case, my isp charges 165 rupees per month, whereas your monthly charge is over 700.
The best trading infra that a serious algo trader with decent trading capital (20+ lakhs) may have is a dual lan motherboard with strong multi-core CPU and decent RAM. Get connections and static IP from two best ISPs in your area and test both of them for order execution latency. Connect the low latency connection as your primary LAN and configure a failover mechanism to the other ISP’s connection in situation where the first connection fails.
If one has the above setup and has/wants to travel while still running the algo and be able to monitor the operations, then simply conect to the above system remotely, while all the operations still happen from the primary location where this setup is putup.
Only in case where one doesn’t have the above setup yet (the only reason for that would be being in the capital building phase of trading) and has to travel, your product will be useful for that brief period, just to use it as the secondary static IP option, before getting back home and operating via ISP’s static IP.
1 Like
Even better imo - AWS as primary atleast for critical time periods and local as backup with 2 networks. Its a bit annoying to setup, but should give best reliability and low latency.
Higher minimum system requirements + Windows licensing fees 
AWS + Local redundant power and network would be very expensive. 
For redundant setups, a more cost effective and reliable approach would be 2 different cloud servers running Linux/BSD. Some of the more popular providers with an Indian location:
- DigitalOcean
- OVH
- Linode (Akamai)
Total cost for 2 tiny servers: $10-15 USD per month 
Depends on needs. These tiny 1 vcpu barely have any power - just one thread, not even 1 core. I need some reasonable multi threaded speeds, atleast comparable to my laptop.
This is where most of the cost will go if we run it all day.
Anyway, i still feel most comfortable with laptop. So I use AWS for critical periods ( or when not in home - has been very very useful for this ) and laptop for rest of the time.
Thanks @eldorado and @SpacemanSpiff for the thoughtful feedback — really appreciate you taking the time to evaluate the idea and share your setups.
I agree with many of the points mentioned here. If someone is technically comfortable running their own infrastructure, a well-configured home setup with dual ISP static IPs or a self-managed cloud VM can absolutely work well.
Where we found a gap (from talking to many traders) is a slightly different group of users:
- Traders who run algos but don’t want to manage servers.
- Traders who use desktop based trading tools but want to avoid exposing their home network through Static ISP IP.
- People trading from office networks or changing locations.
- Users who are not comfortable configuring and securing AWS/VPS machines.
- Traders who want a quick static-IP compliant setup without infra work.
For them, setting up a cloud VM typically involves:
- configuring VPN (WireGuard/OpenVPN)
- setting up proxy routing (Squid)
- firewall rules
- domain + SSL (for securing proxy routing)
- monitoring logs/disk usage
- applying security patches
- maintaining uptime
All doable — but it takes time and ongoing maintenance.
QuanCradle’s managed gateway basically provides that same infrastructure layer pre-configured, so traders can:
- get a fixed Indian IP
- connect via VPN or proxy
- trade from any device/location
- avoid maintaining a VPS themselves
So it’s not really meant to replace well-built home trading rigs. Those are great setups.
It’s mainly meant for traders who want a managed infrastructure layer instead of building and maintaining it themselves.
We’re still early and actively gathering feedback from traders to improve the platform. If anyone here is experimenting with different infra setups, we’d genuinely love to hear your experiences and requirements. Please feel free to join our discord community and give us a chance to talk to you more.
Happy to learn from the community and improve the product based on real trader needs.
From a security and privacy standpoint, relying purely on a static IP from your ISP is often the least safe option for most retail traders.
When you get a static IP from your ISP, your home router effectively becomes permanently reachable at the same public address . The reality is that most home routers:
- run outdated firmware
- rarely receive security patches
- are misconfigured (open ports, weak admin passwords, UPnP etc.)
Once a static IP is assigned, automated scanners and bots can continuously probe that same address looking for vulnerabilities. With dynamic IPs this becomes harder because the target address changes periodically. Static IPs remove that friction.
Static IPs are traditionally meant for business networks , where there are proper firewalls, segmentation, monitoring, and IT teams managing security. Retail setups usually don’t have that level of protection, which is why mandating static IPs for algo trading is questionable from a security perspective.
If a home network gets compromised, attackers can potentially perform:
- credential harvesting
- DNS hijacking
- man-in-the-middle attacks
- internal network scanning
At that point the risk goes beyond trading — it can affect banking, email, and other personal accounts .
Keeping fully managed gateway servers aside, even a self-managed VPS or cloud server is a safer architecture for most people. Even if the VM gets compromised, the attacker only gains access to the VM — not your home network or personal devices.
Using HTTPS APIs already ensures encrypted communication between your system and the broker. Between Proxy and VPN, a well configured Proxy is a better option than VPN in many cases when it comes to security.
Feel free to reach out to us in case if you need any guidance on securing your trading setups. We would be happy to help our fellow traders.
Agree that from a security standpoint, using a gateway server would be so much secure.
I’ve one query and one suggestion:
From a latency stand point, what’s the additional delay (if any) in micro seconds when used your product vs using a ISP provided static IP for an order api request to be sent and receiving a response?
As previously mentioned, my isp being a local provider, seems to have offered me a static IP at a very reasonable cost of 170 rs per month (2000 one time payment for a year). When enquired with national ISPs such as Airtel, the static IP monthly cost was 350 rs (including GST added to the bill monthly).
For a reduced cost for 6 months/yearly subscription to your product, if the cost per month is comparable to 350 rs and more importantly given that there is negligible/no latency vs ISP provided static IP, I would switch from ISP static IP as soon as it’s one year validity period ends
Could offload the heavy tasks to an inexpensive dedicated server provider like Hetzner:
I am looking for an inexpensive Windows VPS like this
staticip.in/vps
Its run by the same guy that runs the ethical telegram group “Python Trader”
Are you using a floating IP with these providers so if your compute node goes down, you can move it to a different one minimizing downtime? Do you have an uptime SLA? 
v4 or v6? 
The monthly plan’s price is 850 INR after discounts!
Thanks for the question — that’s a very valid consideration when evaluating any infrastructure layer.
Regarding latency, the exact delay can vary quite a bit depending on several factors such as your ISP latency, your location, broker server location, and the route your traffic takes across networks. Because of this, the latency we measure from our infrastructure will usually be different from what an individual trader experiences from their own network.
For that reason, the most reliable way to evaluate it is to spin up a gateway and test the round-trip latency directly from your setup to the broker APIs of your choice. That will give you a much more accurate picture than any generic number we could quote. We do offer a 7 days plan for short term usage or testing purpose.
It’s also worth noting that comparing a gateway architecture vs an ISP static IP setup isn’t exactly an apples-to-apples comparison. In the gateway model, requests typically flow:
Trader machine → Gateway server → Broker API → Gateway server → Trader machine
So there is naturally an additional network hop, and some latency overhead is unavoidable.
However, when comparing with the self-managed VPS + VPN/proxy setups that many traders are building, our managed gateways are designed to minimize that overhead. The servers run on DO infrastructure with high-quality network routing, and the VPN/proxy layers are optimized specifically for trading workloads to keep the additional delay as low as possible while maintaining security and isolation.
In practice, unless someone is running a very carefully engineered VPS setup on high-end infrastructure, the performance difference between a typical self-managed setup and our managed gateway is usually minimal, and in many cases the managed gateway can actually perform better due to optimized networking and infrastructure.
For most retail traders who are not doing HFT, the additional latency from a gateway hop is generally negligible compared to overall internet latency and broker processing time.
On the pricing side, the gateway servers start at just ₹716/month, which includes the managed gateway infrastructure, a capable VM, fixed Indian IPv4 IP, high performance VPN/proxy access, and ongoing maintenance and monitoring of the environment.
That said, if someone already has a reliable ISP static IP setup that works well for them, that can certainly be a cost-effective option too. Our platform is mainly aimed at traders who prefer not managing infrastructure themselves or who want the flexibility to trade securely from multiple devices and locations without exposing their home network.
Always good to see traders carefully evaluating these trade-offs 
Great questions — happy to clarify.
For our DigitalOcean gateways we currently do not use floating IPs (reserved IPs).
The main reason is that with DigitalOcean, floating IPs primarily help with ingress traffic, while in our case the egress IP (outgoing IP) is what matters most because that is the IP traders whitelist with their broker APIs.
Every DigitalOcean VM already has a default public IPv4 address, and outbound requests go through that IP. Even if a floating IP is attached, outbound traffic still leaves through the VM’s default IP.
So if a VM were to completely disappear and a new one was created with the floating IP reassigned, the proxy/VPN traffic would still egress from the new VM’s default IP, not the floating IP. That means the whitelisted IP would still change.
Because of that behaviour, floating IPs in DO don’t actually solve the core requirement of keeping the outbound IP fixed.
In practice, the only thing required to preserve the IP is ensuring that the VM itself is not destroyed. Normal events like VM restarts, maintenance reboots, etc. do not change the IP.
Also, the scenario where a VM completely disappears mid-market hours is extremely rare. Building complex failover infrastructure purely for that edge case would significantly increase costs for everyone.
Azure failover work and future redundancy plans
That said, we are already experimenting with a similar setup on Azure, where floating/public IPs behave differently and outgoing IPs can remain consistent across VM reassignment.
This allows us to design a true failover architecture where:
primary gateway → fails → secondary VM takes over → same public IP continues
However, implementing this properly requires:
- real-time health monitoring
- automated failover orchestration
- maintaining VPN/proxy credentials during failover
- ensuring traders don’t need to update configs or credentials post failover
Because this infrastructure is significantly more complex and expensive, we would likely offer it as a premium high-availability option for traders who specifically require that level of redundancy.
The other architecture we’re exploring is: DigitalOcean gateway (primary) + Reserved IP in Azure (standby)
If DO ever experiences an outage, we can failover to Azure using the already-whitelisted reserved IP, without the trader needing to run an active Azure server full-time. This allows redundancy without paying for two active servers continuously.
IPv4 vs IPv6
Currently we provide IPv4 addresses.
In practice this works for 100% of broker/API use cases today, and both DigitalOcean and Azure require an IPv4 address for the VM anyway. Adding IPv6 doesn’t provide a practical benefit for most trading setups and doesn’t significantly change pricing either.
If the ecosystem moves toward IPv6 in the future we can certainly support it.
Uptime SLA and Pricing clarification
Our uptime is tied to the SLA of the underlying cloud providers:
- DigitalOcean: 99.99% monthly SLA
- Azure: 99.9% SLA
So as long as the underlying infrastructure is up, the gateway remains available.
The monthly subscription is ₹849. If you subscribe quarterly, the effective price comes down to ~₹716 per month, which is what was referenced earlier.
We’re still iterating on the infrastructure and exploring more reliability options. If anyone here is interested in discussing architecture details or testing different setups, feel free to join our Discord — we would be happy to dive deeper into these topics and share the design approaches we’re experimenting with. We are also adding technical blogs here to help traders understand our product better.
Hey @pavinjoseph, thanks a lot for sharing this — we had actually missed that detail. Looks like DigitalOcean does allow outbound traffic to exit via the reserved IP as well, which means we can potentially design an automatic failover setup within the DO network itself. Really appreciate you pointing this out.
Also a quick update for anyone interested — we’ve started a trial campaign until March 31st. You can get a free gateway server for 3 days to test your setup and see if it works well for your use case.
If you decide to continue, you can simply extend the server validity and keep the same IP. If not, the gateway will automatically expire and be deleted after 3 days. You can always spin up a new one later if needed.
If you’d like to try it out, sign up at https://www.quancradle.com/
and then DM us on our Discord community (QuanCradle - Traders' Community). We’ll add trial credits to your account within 24 hours, which you can use to launch a gateway with a 3-day validity anytime before the campaign ends.
Note: Our Discord community is the official communication channel for QuanCradle. All announcements, downtime notices, and updates are shared there. If you run into any issues with your gateway server, it’s also the fastest place to get support.
1 Like