Is using an Organisation still the recommended way of isolating environments

Hey I’m just exploring how I go about deploying docker images and isolating between environments e.g. staging/production

Originally my plan was to create two apps appname-saging and appname-production but looking at the docs you recommend two separate organisations. So now I was wondering do I need to specific the organisation in the config files? I don’t see how I do that or are app names unique so I’d still need to create two app names above?

The other thing I was trying to investigate is how I go about using the same docker images with the fly.io registry but I can’t seem to figure out whether this is possible

For example I push a docker image up with a tag name that matches my git hash that then gets deployed to staging.
Then if tests pass I want to then tag that image with a semantic version and deploy it to my production app.

Is this possible or do I need to explore another pattern for doing this?

oh hey @aranw

Originally my plan was to create two apps appname-saging and appname-production but looking at the docs you recommend two separate organisations.

It’s totally fine to keep both apps in one org if you don’t need the isolation(members, separate billing controls, and separate private networks) that separate orgs provide.


I don’t see how I do that or are app names unique so I’d still need to create two app names above?

Yes app names are unique, and so you would have to.


The other thing I was trying to investigate is how I go about using the same docker images with the fly.io registry but I can’t seem to figure out whether this is possible

Here’s how you re-use an image hosted on our registry

fly deploy --image registry.fly.io/name:tag

For example I push a docker image up with a tag name that matches my git hash that then gets deployed to staging.
Then if tests pass I want to then tag that image with a semantic version and deploy it to my production app. Is this possible or do I need to explore another pattern for doing this?

Are you tagging the image yourself using a docker client? If yes, then you can definitely do that. Just push your new tags to our registry and just point flyctl to the new image, just like I showed up there.

1 Like

Yeah I was looking at tagging the images on each “deployment” to various environments

I’m guessing there’s ACL restrictions on these images that prevent users from trying to access images that don’t belong to them

I’m also guessing a docker image name must match at least one registered application in the Fly.io platform?

If you only need separate private networks, but not separate members/billing, you can create the application and attach it to a custom network (fly apps create my-app --network my-custom-network). This way the application will get it’s own /48, which is isolated from the default /48 of your organization.

Note that fly ssh console and fly wg create do not support custom networks. You can create a WireGuard peer using GraphQL API. After the WireGuard tunnel is active, you can issue SSH credentials (fly ssh issue) and establish a SSH connection via ssh (instead of fly ssh)

I just wanted to expand on this. I’m guessing there’s some limitations and isolation but I’m trying to figure out where that begins. Is it Organisation level? Or Account level?

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