Public API for launching containers?

Hi team!

Does Fly support a public API that I could post HTTP to, to spin up a new app?

I’d love to be able to offer my customers (who aren’t very technical) the ability to spin up specific docker containers with the push of a button on a website.

Much love, Hugh

We have two public APIs actually:

I really feel like you need machines! We talk more about it here: Fly Machines: an API for fast-booting VMs · Fly

Thought I must say GraphQL is prone to changes so stay tuned on the Playground to be up to date with our format.

2 Likes

Perrrrfect yes Machines API is exactly what I’m looking for :slight_smile:

Thank you!

1 Like

@lubien - is there a way of provisioning volumes via the API that can be used with each Machine?

You can, but it’s not well documented. We haven’t officially released volume support for machines yet, but you’re welcome to use it.

If you create a volume, you’ll see an ID for it in fly volumes list. You can pass that to machine run like this:

fly machine run <img> -v vol_70zy6r7y763rdjng:/data

That will mount vol_70zy6r7y763rdjng at /data. If you get this wrong, you won’t get helpful errors yet. :slight_smile:

1 Like

Thank you @kurt and @lubien - I’m looking for a HTTP API for provisioning and attaching Volumes to machines (via Machines API). The examples above seem to be for the CLI!

Do you know roughly when the HTTP API for the above might be ready?

Oh, everything in flyctl uses an HTTP API. The createVolume mutation is on our GraphQL API, here’s how it gets called: flyctl/resource_volumes.go at 994c20db1aaed2cec82d5f3f930f461a95aba030 · superfly/flyctl · GitHub

The -v argument gets turned into mounts on the generated machine config: flyctl/types.go at e1a65d5b087684092c2ffb880d43f343dd79c59e · superfly/flyctl · GitHub

Gotcha! I’ll reverse engineer the CLI for anything that’s not in the formal API docs. Thank you team!

Hi,

Were you able to build the website where your customers can launch fly instances through it?

If so, Can I ask you about the approaches you’ve taken? Especially concerning,

  1. Authentication

  2. Persistent Storage (volumes)

  3. Database (Access to PostgreSQL)

P.S. Forgive me for commenting on a solved topic, But this seems to be the only thread discussing about the platform API and so thought it’s better to reply than opening a new thread.

Can you briefly mention the approaches you have investigated? If not, it is asking lot for folks to (from the scratch) design a SaaS on the fly (no pun).

Fair question.

Here’s what I’ve investigated so far and in hindsight should have mentioned in the previous comment.

My first plan was to use the heroku platform api but I’ve noticed that fly is better in terms of performance and value so I started looking into the platform API for fly to build a SaaS application.

API:

Machine API:
Which seem to be providing low level access to the VMs. But in my case I would prefer using general work flow as in flyctl as micro-managing VMs wouldn’t be necessary from the start and more importantly I want my non-technical customers to make use of the free tier first and then move on to become paying customers after they exceed the threshold.

Besides it seems like I have to find other mechanisms to manage storage and database anyways when using the Machine API.

GraphQL:
I could use it as a reference, TBH I’m not entirely sure where to begin as I’ve not used it before.

flyctl Go client:
Since the client is open-source(& very readable) and that I’m comfortable with Go I’m thinking of directly integrating the client into my web service with necessary modifications. A quick glance of the code showed me the separation of API and the commands; So I could write helpers to access the API directly. This is my preferred choice so far(Unless someone here convinces me otherwise).

Authentication:
My first step is Auth, Because everything else becomes irrelevant if I cannot authenticate my users with fly platform safely.

I presume getting the fly login URL to the user would be the easy part, What I don’t know is how flyctl treats different IP addresses (One for login URL generation [My service], One which actually logins into the account[My customers]).

I’m planning for a test with VPN, But even if I succeed with it, if IP verification is enabled suddenly then my authentication would fail.

If I were you, I’d integrate with Fly’s GraphQL APIs, as it seems to be officially supported by Fly, rather than hook into a codebase like flyctl’s (but nothing wrong with it either, as I’d wager flyctl inturn uses GraphQL APIs underneath).

Re: Auth: I guess you can ask users to add ‘access tokens’ (like GitHub Secrets) that you can store in your vault on user’s behalf. Using these tokens should let your service perform operations the user has authorization for (access tokens are tied to a user, that is, if a user is removed from an org, then that user and by extension the tokens that user generated, lose access to the org’s resources). More: How does flyctl deal with authentication?

Fly hasn’t released scoped-tokens yet: Google OAuth for Organization logins - #2 by thomas

What I don’t know is how flyctl treats different IP addresses

I don’t understand what this means in this context. You mean a scenario where a token is generated by one IP (via flyctl login) and then immediately used by another, different IP? I don’t think that should be a problem. If not, I may have misunderstood your question. At any rate, such deep integration with Fly means one’d ideally want to run any design past Fly’s eng team (ie, paid support: Coming soon: paid plans and support, oh my).

2 Likes

I appreciate the suggestions.

I’d wager flyctl inturn uses GraphQL APIs underneath

Yes, As Kurt had mentioned in the earlier comment and hence I prefer to use it directly but I understand that I have to monitor for changes constantly.

I guess you can ask users to add ‘access tokens’

Issue is my customers would be non-technical and at best only thing which can be expected of them with fly platform is to create an account and pay for bills when the threshold is reached. Another reason for why I feel hooking on to flyctl is the best option here until OUTH2 is available.

You mean a scenario where a token is generated by one IP (via flyctl login) and then immediately used by another, different IP?

Yes, I was able to create the login URI from one IP and login into the account successfully using another IP (From another country); Although it did trigger 2FA, Which was expected.

paid support

I would consider paid support once I validate the product, I do see the chicken-and-egg here but I guess I just have to build it considering there doesn’t seem to be a glaring technical barrier (Although I would appreciate comments from the team if there’s any).

1 Like

Gotcha. Makes sense to build atop flyctl in that case. Another alternative (for a prototype) could be a greasemonkey script / browser extension that injects styles, markup, and js into the Fly dashboard?

I guess I just have to build it considering there doesn’t seem to be a glaring technical barrier

I guess. You’re going where no user on this forum is likely to, so you are the one blazing a trail for the rest of us! Good luck.

1 Like

Ooh! To show the user the access token in the home page in large bold like,

Give this token to the [product name] when asked’ ?

An interesting solution, But I’m afraid about the security implications as if the product indeed works out, There will be dozens of fake extensions trying to exploit the user. Besides, I myself is a strictly no 3rd party browser extension person; So I’m not sure whether I can impose it on my customers.

Thank you! I’ll try my best.

1 Like