Ciao 
I am trying to host a remote gRPC server on a space. I can provide more context on why that’d a useful way of showcasing robotics demos
I am setting everything up using a Docker Space, with my Dockerfile simply running python server.py, which executes just fine per the logs:
However—despite the same container running just fine locally—I keep on (1) hitting a 500 error and (2) not being able to connect to the server.
(1) The space id: fracapuano/remoteserver. I read somewhere this corresponds to this URL: https://fracapuano-remoteserver.hf.space
(2) Logs from the remote server space:
===== Application Startup at 2025-04-29 07:56:29 =====
/usr/local/lib/python3.10/site-packages/google/protobuf/runtime_version.py:98: UserWarning: Protobuf gencode version 5.29.0 is exactly one major version older than the runtime version 6.30.2 at async_inference.proto. Please update the gencode to avoid compatibility violations in the next runtime release.
warnings.warn(
2025-04-29 07:58:10 [SERVER] [INFO] PolicyServer started on port 8080
(indicates successful built with no errors)
Error message on the remote client, trying to connect to access the server using gRPC as a communication protocol:
2025-04-29 10:13:10 [CLIENT] [INFO] Robot connection time: 0.0125s
2025-04-29 10:13:10 [CLIENT] [INFO] Robot connected and ready
2025-04-29 10:13:10 [CLIENT] [ERROR] Failed to connect to policy server: <_InactiveRpcError of RPC that terminated with:
status = StatusCode.UNAVAILABLE
details = "DNS resolution failed for https://fracapuano-remoteserver.hf.space: C-ares status is not ARES_SUCCESS qtype=A name=https is_balancer=0: Domain name not found"
debug_error_string = "UNKNOWN:Error received from peer {created_time:"2025-04-29T10:13:10.887328+02:00", grpc_status:14, grpc_message:"DNS resolution failed for https://fracapuano-remoteserver.hf.space: C-ares status is not ARES_SUCCESS qtype=A name=https is_balancer=0: Domain name not found"}"
>
2 Likes
Might be worth flagging pinging the remote URL doesn’t work!
export SERVER_ADDRESS="https://fracapuano-remoteserver.hf.space"
(base) ➜ ~ ping $SERVER_ADDRESS
PING https://fracapuano-remoteserver.hf.space (34.241.150.125): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
^C
--- https://fracapuano-remoteserver.hf.space ping statistics ---
8 packets transmitted, 0 packets received, 100.0% packet loss
(base) ➜ ~ ping 34.241.150.125:8080
ping: cannot resolve 34.241.150.125:8080: Unknown host
(base) ➜ ~ ping 34.241.150.125
PING 34.241.150.125 (34.241.150.125): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
^C
--- 34.241.150.125 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
(base) ➜ ~
1 Like
It seems that the open ports are changing, and it may be unclear which ports can be used unless you are a Hugging Face staff member…
Turns out I am 
I joined couple of weeks ago—slack me at @francesco.capuano?
1 Like
Oh… I don’t use slack. Well, contacting HF is the safest bet, but contacting them on HF Discord might be faster. website@huggingface.co
Makes sense, thank you! Just for me to make sure I understand the issue (and to document it!)—what is exactly going wrong here?
Locally or on machines connected through internet everything runs just fine, so is it a matter of ports when trying to read from the space?
1 Like
I think it’s simply that the virtual machine in Space has limited ports open to the outside, and access to other port numbers is being blocked.
It seems that it has been misused in various ways, so restrictions have been tightened considerably. Well, it’s a common occurrence.
So, the workaround is to find the port numbers that are currently open and access them, or request HF to open any well-known port numbers that should be open but are not. Maybe.
Hi @fracapuano!
I’m trying to do something similar Did you get any update on the feasibility?
1 Like