NestJS Microservices (TCP Connection Refused)

I’m trying to deploy some microservices writing in Nestjs (NODE) which connect via TCP. I’m using internal docker addresses and default port (8080) for each service. But when I run fly launch i got this errors in VM:

230cd37130e7f9c96f951ed2ad499c8f tcp-8080 critical dial tcp connect: connection refused ```

Then, my deploy failed because health check

Description = Failed due to unhealthy allocations - no stable job version to auto revert to
Instances = 1 desired, 1 placed, 0 healthy, 1 unhealthy

Can anyone help me ? There's a discord/slack community ?

Can you maybe see some logs to see why it failed? With fly logs? Most apps should put some kind of stacktrace/exception/message to say if something failed.

One possible issue with Node is it’s only listening on IPv4, and Fly’s internal network uses IPv6. So make sure your server is listening on ‘::’ e.g it may look something like this:

server.listen(8080, '::');

When you deploy Fly’s system will check the tcp connection to it is working and if not, that would indeed result in the deploy failing:

There is a grace period option there, so another thought would be if your app takes time to start, you could up that time a bit in your fly.toml to e.g 5s

My service runs with no errors when i use either or :: as host value. But how can I connect other service with this one?

I’m trying to use internal fly addr. ex: lax.service-one.internal to connect service-two.

User Microservice

It’s runnning on port 8080, in default address.

Then, other service would connect from lax.user-microservice-internal in port 8080. does it ?

Well I haven’t used Nest, my thoughts were for general Node. But yes, listening on :: like that looks ok to me. It sounds like the healthchecks in your first post must be passing now in order to get that app deployed, else it wouldn’t even get to that point.

As regards connecting to it from other apps, yes, assuming they are in the same organization, you should be able to connect using e.g http://app-name.internal:8080. You use http because the connection is already encrypted.

Personally I would experiment with the hostname. Like try using http://app-name.internal:8080. If that works, next try e.g Try and narrow down the failure that way. If e.g the hostname without the region works, but with it does not, that would be one for Fly to investigate.

You’re right!

I did it just changing listenning hostname to :: like above. Then i defined envs in fly.toml with the fly internal address.

It works!

Thanks a lot @greg

1 Like

You’re welcome :slight_smile: Glad it worked.