looking for some general guidelines for app deployment on fly

1

I have an identity server I’m trying to deploy which will only be used internally by other fly apps, it has a admin UI but its (currently) only accessible over SSL which it seems fly proxy does not handle (to my knowledge)

if my apps are only communicating with sevices via the private fly networks, should I use SSL at all? or should I only be running a service via HTTP and fly will take care of the TLS/HTTPS termination if something is a public endpoint?

2

It depends on your security needs but using HTTP for internal only communications is okay because fly uses Wireguard encrypted tunnels so communication between apps inside your organization is already encrypted. Having their proxy do TLS termination for incoming external connections is quite a standard setup.

2 Likes
3

Hey thanks for the response, in terms of communicating between web services how would that work? with the .internal TLD or the .flycast I read somewhere that I need to bind to the 6pn ip but if its already bound to 0.0.0.0 is that still a requirement?

some general guidelines of internal communication across services would be super helpful!

4

Depends on whether you want to use the proxy or not.

If you don’t need any of the proxy features then using the .internal addresses will work fine.

If you do need to use the proxy then you’ll need to assign a private ipv6 to each app that you want to be accessible via the proxy and use the .flycast address to access those apps.

As for the apps, they don’t need to change, you can continue binding to 0.0.0.0 though I normally bind using the ipv6 address of [::].

Some basic guidelines are:

  • For http based apps, if you’re talking to a specific VM or to the closest VM, you don’t need the proxy. If you want internal load balancing without managing it yourself then you do need the proxy.
  • For TCP based apps, same applies but load balancing happens at the connection level instead of the per request level like http.
  • For UDP based apps, if using the proxy, refer to fly docs about binding for UDP as things work a little differently.
  • Be aware that by default all apps in an organization can internally talk to each other, and there’s no restriction on which ports they can talk to each other on.

Without more details on your specific requirements, this is about as much information you can get.

1 Like
5

Thanks for your response! For the proxy are you saying that you would actually run the proxy on the deployed app? E.g. fly proxy?

The topology I’m dealing with is all services I think will be internal apps, except the node web app.

I have a keycloak identity service, a few Java micro services and a node app.

Ideally all of them communicate via private network and the only thing that is exposed publically is the node app.

Though I’m not entirely sure if I’ll be able to do that with keycloak yet.

Given these circumstances do you have some recommendations?

6

Unless you’ve got some unique requirement, I’d use the fly proxy instead of setting up your own.

I would personally use the fly proxy for all the apps if possible as it provides load balancing. You can set private ipv6 addresses and no public ip addresses on the internal apps and use the .flycast addresses, that way they’re not publicly accessible.

You’ll have to make sure that all of your services can operate in high availability environments, e.g. Sessions not stored on local disk and instead stored on a storage accessible by all VMs for that app.

I don’t know enough about Keycloak to give advice on it so here’s the official docs for production recommendations Configuring Keycloak for production - Keycloak.

1 Like
7

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.