What is our primary use case?
I work as a software developer at ADP and I majorly work with a lot of AI tools. My day-to-day work involves coding, shipping code, and deploying applications. Apart from my work, I also have an agency wherein we develop websites for clients, and we use a lot of AI there as well. My entire day is accumulated with coding and AI work.
We develop a lot of APIs and webhooks for the tech systems that we build, and I use ngrok for web testing and webhook testing. I also share demos with my teammates by exposing local APIs during development. As a team, we validate all integrations without deploying them to production or staging. We make sure to deploy everything in lower environments, replicate things, and test them thoroughly before confidently deploying into production.
The scope is very broad. I use ngrok anywhere to expose a local app, and all my teammates use it as well. We majorly cover webhook testing, local API exposure, and we share demos with teammates and clients. I also use it for debugging integrations and temporary public access for front-end and back-end builds. It saves a lot of time across development and QA. Additionally, we use it for demos and integration work. If I say the scope is big, it is quite big because especially for all the developers and QA engineers building APIs, ngrok is majorly the go-to tool.
I use ngrok in the web agency that we have outside of work. In the web agency, we are a team of eight people and we use it rigorously.
What is most valuable?
The best feature of ngrok is how quickly it creates secure tunnels for local services. The one that I use the most, and that my team uses the most, is the public tunnel URL because it helps me to test webhooks, share demos, and expose local apps instantly. We often use it the most, and my favorite would be the public tunnel URL.
ngrok has a few advanced features like traffic inspection, reserved domains, and more detailed observability options that my team and I haven't used much yet. For my day-to-day work, the basic secure tunnel and public URL are the features that I rely on the most. There are pretty advanced features that we are trying to explore now and probably use them down the line.
ngrok has positively impacted the organization because it was able to reduce the time needed to expose local services for testing, demos, and webhook integrations. It has helped teams to move faster, collaborate more easily, and avoid the overhead of setting up temporary public environments. On a holistic note, ngrok has a very positive impact on our organization.
What needs improvement?
The biggest friction point I faced with ngrok was the limitation on the free plan and the occasional need to manage sessions or URLs again. For very heavy use, the advanced capabilities are very useful, but some of them feel quite restricted unless you are on a paid tier. ngrok works very well, but the main frustration is when you need the same tunnel setup repeatedly or want more advanced controls. In those cases, you start to feel the pain.
I wish ngrok had more flexibility in the free or low-tier plans, especially around persistent tunnels, reserved URLs, and usage limits. It would also be very useful to have even better traffic analytics and easier collaboration features for small teams.
If I could change one thing about ngrok, I would make persistent tunnels and reserved URLs more flexible in the lower plans. That would make my workflow smoother because I wouldn't need to keep redoing tunnel setup for repeated testing and demos. Making persistent tunnels and reserved URLs more flexible in the lower plans would change my workflow by reducing repeated setup and making webhook testing and demos faster while giving the team more consistent URLs for local services.
For how long have I used the solution?
I have been familiar with ngrok for about one year now.
Which solution did I use previously and why did I switch?
Before ngrok, I was using manual port forwarding and temporary deployment setups. After ngrok, it quite simply simplified that a lot by giving me a secure public URL in just a few minutes, which I was able to use to show demos for clients in the web agency that we are building right now. Before ngrok, I had to rely on manual workarounds, but ngrok replaced that with a much faster and easier workflow.
When I was evaluating options along with ngrok, I considered manual port forwarding, local tunnel, and Cloudflare Tunnel. When evaluating options, I considered manual port, local tunnel, and Cloudflare, but ngrok stood out because it was easier to set up, more reliable, and it was better suited for quick development and webhook testing. When I started using it, I felt it was quite easy for my team to adopt it. There was no second question; we went straight to ngrok.
How was the initial setup?
When I first implemented ngrok, the implementation was very quick to start running. If I remember correctly, it was a few minutes to start running. The first time I implemented ngrok, it was just about a couple of minutes or three minutes to get it running. Once my local app was up, creating the tunnel and getting a public URL was very straightforward. Most of the time was spent checking the local app and choosing the correct port, not on ngrok itself.
It was quite easy to pick up and my team didn't need formal training because ngrok was very easy to adopt and the setup was intuitive. We were able to start very quickly with the basic documentation that was available on the site.
What other advice do I have?
For someone with a similar use case or for teams with a similar use case, I would recommend starting with a basic secure tunnel workflow using ngrok for quick testing and demos, and then moving to the paid plan if you need persistent URLs and more flexibility. I would ask them to start with the basic tunnel workflow and then once they are familiar with the workspace, they can move to a paid plan because they would get the persistent URL that they can use flexibly across the team.
One thing to know about ngrok is that it is excellent for quick, secure exposure of local services, but it is mainly a development and testing tool rather than a production hosting solution.
ngrok did change team collaboration because earlier it was quite a waterfall model. Everyone was developing and we were not given a chance to see the things that were built locally. Today, with ngrok, we were able to utilize the public URL and instantly demo the features that we develop. As a team, we held up the spirits because everybody is charged up to deliver quickly and to show the version that they have locally.
As a web agency with eight people on the team, ngrok has improved productivity for all eight people by reducing setup and debugging time. If each person saves just 30 minutes a week on webhook testing, local exposure, and demo setup, that adds about four hours saved per week across the team. Over a month, that is roughly around 16 hours saved, which is a very meaningful productivity gain. At a team holistic level, it was somewhere around 20 hours saved a week. That immensely boosts the productivity of the team.
The first thing that I would do is run a tunnel for the local port of the app that I am using. When opening the terminal, I would run something like ngrok http 8080 to expose the local service securely. That is the primary thing that I would do.
I would rate ngrok a 9 out of 10.