We have a need to expose an external port that is TCP, not HTTP. Is this something that is possible? From, the UI it appears I can only expose HTTP.
Hi @rjohnson , it’s not possible at the moment, but it’s something we can do pretty quickly. (we didn’t have requests for that, most companies/users expose HTTP or gRPC protocol outside their network). Can you explain more about your use case and why you need to expose your app over TCP?
Thank you 
Hi @rophilogene , we are communicating with a IoT device provided by a third party company that uses a custom protocol (similar to gRPC) that we don’t have a way of changing.
Thx. We can add the support of exposing TCP - I need to loop with our team to see when we can do it and when it will be available for you.
Hi @rophilogene , just checking if you had an estimate on the timeline for this? Thanks again!
Hi @rjohnson , not yet but I’ll come back to you next week on this topic cc @a_carrano
I can see GRPC can now be publicly exposed but it’s not usable.
It’s unreachable both within and outside the network.
Within the same network
Outside the network (when we were trying to debug)
Any timelines as to when this could be fixed/resolved?
Hi @rjohnson - exposing TCP (and UDP) port is now supported 
cc @a_carrano
Hi @rophilogene,
That’s great! I watched the video and noticed the extra cost associated with this. Do you know roughly how much it would cost to have a service running like this?
Again, thanks for the quick turnaround on this!
Thanks,
An NLB (Load Balancer used for TCP) in US regions costs around $17/month (750h). You can take a look here.
At some point, we will provide environment and resources costs right from Qovery - but at the moment, we are still waiting for this kind of integration. (you can still use products like Kubecost to control your costs.)
Let me know if you have any questions
Hi @rophilogene ,
So will we need a NLB for every service that we expose via TCP? We were planning on having a service exposed via TCP in every environment.
If the HTTP port free because it is behind a HTTP proxy that you run on your side? I was imagining that the TCP port would be handled via a similar mechanism to the HTTP port, but I may be a little confused.
Thanks.
Yes
Indeed, it will be an extra cost per environment. Unfortunately, there is no simple answer here. Since it’s TCP traffic, we can’t use the same port from the same NLB for multiple apps.
Do you plan to have multiple long-running environments? If it’s not the case, the cost will be almost negligible then.
HTTP is a layer 7 protocol; it’s possible to proxy multiple services behind the same port and load balancer. However, it’s impossible to do the same for TCP (Layer 4). (Actually, it is, but it’s not worth it in terms of complexity and cost).
I have no simple answer; those costs are AWS based, and unfortunately, we can hardly optimize them. But I can still see with my team what we can do.
I hope it’s clearer for you @rjohnson
Sounds good, thanks for the extra information @rophilogene!
1 Like
Hi Robert, let me check on my end with the team.
Hello @rjohnson,
I am sorry for the inconvenience. We are experienced an issue with the TCP protocol for Containers during the creation process that we have already resolved, we’ll release today
If you’d like to proceed immediately, you can bypass this problem by creating your Container without specifying Ports. You can then add the necessary Ports in the settings section.
Please feel free to reach out if you encounter any further issues.
Best,
Rémi
2 Likes