I need to deploy a small Node service for responding to Pub Sub events which won’t even listen to HTTP.
Would this work fine with Fly? Do you need HTTP to work for health checks and so on?
You can, it’s a little hacky though. They do require a network service of some kind .
We run Buildkite agents like this, they export Prometheus metrics over port 8080.
We’re planning on adding worker support any day now so you can avoid the hackiness. 
2 Likes
“hackiness” it’s a technical term, right? 
Great, I will just use it locally until it can be deployed to Fly as a worker!
Looking forward to workers 
@kurt Any luck on the workers? I just joined fly and my app has two parts two it. One that serves HTTP requests (and needs to scale), and the other is a Job handler which should remain at 1. Is this currently possible?
I’m pretty sure you can just configure the app without any services configured and it can act as a worker.
This doesn’t auto scale, but running it at a scale of 1 would give you the worker you need.
Thanks for the response, this results in two different apps right? Is it possible to have them under one app so that running the deploy command would publish them both?
Not at the moment. It’s been mentioned before that they want to better handle the worker + web app, but that’s not something they’ve solved for yet.
You’ll need a separate app for the web service and an app for the worker. They can be scaled independently.
1 Like
Not a way to deploy two apps from one command, but you could write a wrapper script around the deploy command.
See the docs on the deploy command.
Basically you can use the —config and —app flags to deploy two separate toml files and apps, respectively.
It’s not ideal, but it should work okay.
1 Like
Yeah I’ll do this for now but I hope this is on the roadmap, the original response was from 6 months ago. Thanks for the help!
Anytime!
1 Like
It has been a while! Once we get postgres buttoned up I think this will become more important since it’s common in fullstack apps.
2 Likes
Just chiming in that this is something we’d be interested as well! Going to work on setting it up as a standalone app w/o a services fly.toml section for the time being.
1 Like
This is now a lot more common. We do that for our own apps.
Simply omitting the whole [[services]] section of your fly.toml should do the trick!
3 Likes
2 Likes
I removed the whole [[services]] section and I think that broke something as the deploy couldn’t finish now.
I then tried just removing the HTTP services for 80 and 442, or even adding everything back again on the fly.toml file, but nothing fixed it.
So finally I deleted the app and started from scratch. Now the deploy process seems to be fixed… but after 5 mins of waiting I got:
Failed due to unhealthy allocations
Am I doing something wrong?
Is there a guide for deploying non HTTP apps?
Edit:
After a couple of hours of trying stuff I just ended up adding an HTTP service to my worker…
Hopefully this will be more polished in the future.
The trick here is to keep the [[services]] header but remove the rest. We know this is terrible, but that should work.
2 Likes
Thanks @jsierles that was it!
Edit:
Maybe you could throw an error if the services block is completely missing when doing the config checks.
==> Verifying app config
--> Verified app config
@jsierles is there any other trick to make this work with a Dockerfile and no build?
I’ve changed my worker app from using the Node buildpack to using a Dockerfile. To do that I simply removed the build section of the fly.toml. When deploying everything works fine until the health checks which fail.
1 desired, 1 placed, 0 healthy, 1 unhealthy [restarts: 2]
I’m assuming it’s because the app has no HTTP services?
The empty [[services]] is still there.
Edit:
It was a user error. Sorry to have pinged you.
3 Likes
hey @pier would you mind posting or linking your final fly.toml? i’m trying to do a similar config and would love to see where to start from in one place