Skip to content

Update nav to add links for the "one app per customer" doc #2013

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 22, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions machines/guides-examples/one-app-per-user-why.html.markerb
Original file line number Diff line number Diff line change
@@ -1,8 +1,10 @@
---
title: One app per customer - why?
title: One App Per Customer - Why?
layout: docs
order: 15
nav: machines
categories:
- machines
---

We recommend that you create one app, with one or more machines, **for each customer** you have. You'll gain a lot from this:
Expand All @@ -24,7 +26,7 @@ Each Fly.io organization gets an isolated network that connects all machines in

However, at application creation time, a `--network` parameter can be passed, to create a [custom private network](https://fly.io/docs/networking/custom-private-networks/) for that application. This subnet will not be connected to the organization’s, meaning this application will be isolated from others (although it can still provide a public internet-facing service as configured in `fly.toml`).

The [Custom private networks](https://fly.io/docs/networking/custom-private-networks/#private-apps-with-flycast) document details a few ways an isolated app can talk to other applications in a controlled manner, including:
The [custom private networks](https://fly.io/docs/networking/custom-private-networks/#private-apps-with-flycast) document details a few ways an isolated app can talk to other applications in a controlled manner, including:

* Application A (non-isolated) can have a `.flycast` IP address in application B’s (isolated) subnet, so they can talk to each other over that IP address. You can do this using `fly ips allocate-v6 --private -a APP_A --network APP_B_NETWORK`. App A can then contact “app-b.flycast” directly.
* Using the [fly-replay header](https://fly.io/docs/networking/dynamic-request-routing/), an application can direct requests to machines in another application, even if that one resides on a private subnet.
Expand Down
1 change: 1 addition & 0 deletions partials/_firecracker_nav.html.erb
Original file line number Diff line number Diff line change
Expand Up @@ -65,6 +65,7 @@
{ text: "Machine Restart Policy", path: "/docs/machines/guides-examples/machine-restart-policy/" },
{ text: "Machine States", path: "/docs/machines/machine-states/" },
{ text: "Run User Code on Fly Machines", path: "/docs/machines/guides-examples/functions-with-machines/" },
{ text: "One App Per Customer - Why?", path: "/docs/machines/guides-examples/one-app-per-user-why/" },
{ text: "The Machine Runtime Environment", path: "/docs/machines/runtime-environment/" }
]
},
Expand Down
3 changes: 2 additions & 1 deletion partials/_machines_nav.html.erb
Original file line number Diff line number Diff line change
Expand Up @@ -37,7 +37,8 @@
links: [
{ text: "Machine restart policy", path: "/docs/machines/guides-examples/machine-restart-policy/" },
{ text: "Machine sizing", path: "/docs/machines/guides-examples/machine-sizing/" },
{ text: "Run user code on Fly Machines", path: "/docs/machines/guides-examples/functions-with-machines/" }
{ text: "Run user code on Fly Machines", path: "/docs/machines/guides-examples/functions-with-machines/" },
{ text: "One app per customer - why?", path: "/docs/machines/guides-examples/one-app-per-user-why/" }
]
},
{
Expand Down