A few questions from a newbie

Hi, I’m new to Fly.io, and I’m using the free Hobby plan to host a Python 3 bot that runs on a website. I love Fly.io so far, but I’m a bit confused about a couple of things.

Here’s some questions I have:

[Answered] 1. When I deploy my app to update it, it also runs another app with a random name, with the status ‘Deployed’. What does this do?

[Answered] 2. Is it possible to update (deploy) an app without having to wait for the reinstallation of all the dependencies?

  1. How do I get a consistent, instant log of the console (printed messages)? I’ve checked the monitoring tab as well as used flyctl logs, but for some reason, the log has a large delay and often misses messages printed to the console. My script works fine, but it’s supposed to print to the console whenever my bot sends a mesasge; however, this doesn’t happen. It even often fails to show the initial prints on start-up, but it seems completely random when they actually appear in the log.

  2. Will I ever be billed unexpectedly? I run one single bot on the Hobby plan currently. I don’t want to be billed unexpectedly. From what I understand, I should be able to run this bot for free forever, right?

Any help is much, much appreciated! I’m quite the Fly.io newbie.

That’s your app serve-able over a (free) fly.dev subdomain. That is, your Fly app would be accessible over the *.fly.dev subdomain assigned to it, if it uses Fly’s built-in HTTP and TLS handlers (which most Fly apps do).

# if Fly is setup to terminate TLS and handle HTTP, then
curl <subdomain-assigned-to-my-app>.fly.dev -I
# should output the same as
curl my.fly.app.domain.tld -I

Not really. You’d have to build the docker image each time. Fly does cache deps in its remote builders, so I take you’re covered if you’re pulling in dependencies via Docker itself (as opposed to, say, downloading deps via package managers like apt/apk/npm etc from within Docker).

You don’t have to sweat about it though; other than making sure the final stage of your multi-stage dockerfile is lean. Fly doesn’t yet charge for its docker builders and docker registry.

Just a guess: Is your main app process running as root? If not, try that.


Re: Surprise bills: See this thread: How concerned should I be about a surprise bill?

I suspect the the other app with the random name is the “builder” instance, which is:

  1. Free :sparkles:
  2. Used to run the “docker build” step that produces the image from with a VM is created

Shortening deploy times (in terms of installing dependencies) often depends on the Dockerfile setup (or buildpack, if one is being used over a Dockerfile). Docker does a decent job of caching build steps, but:

  1. If you destroy your free builder app, no build cache will exist anymore (until your next build)
  2. It’s possible to accidentally setup the Dockerfile in a way where it doesn’t cache dependencies very well

For the logging portion - again this can depend on the application setup in Docker. Generally the “main” process being run should be spitting out logs to stderr/stdout, which Fly can then read (just like Docker’s logging mechanism).

1 Like

What does this mean? Here’s my Dockerfile:

FROM python:3.10
WORKDIR /Bot
COPY requirements.txt /Bot/
RUN pip install -r requirements.txt
COPY . /Bot
CMD python bot-main.py

If I’m only using one scale count and running one application, it will be free, right? I don’t really understand how the Hobby plan works. I would rather the application stops than it bills me.

For compute / builders / registry, yes. For egress, if your app stays within the generous (rationed) 160GB/mo limit. Checkout the pricing page for more info.

It means running the main app process as user-id 0. Don’t worry about it since from the dockerfile you shared, it looks like the process may be running as the default user (which is the root user on Fly). If you’re curious why non-root users do not have access to stdout/stderr, see: Allow non-root users to write to stdout/stderr

1 Like

I don’t quite know what stdout/stderr is. I just want to be able to read my bot’s log. If anyone can point me in the right direction, that’d be much appreciated! (This is my first time hosting a bot online rather than on my computer, so I apologize for the newbie questions.)

Edit: I’ve noticed that the log actually does show up, but it seems to be delayed? The last print in the log was a message that was sent maybe 20 minutes ago.

https://chat.openai.com/chat :wink:

Logs via flyctl logs -a <app-name> are provided on best-effort basis (that said, it has worked for me almost all the time). If you need proper logging, then there’s a bunch more you’d need to do: What are people using for search these days? - #2 by ignoramous

1 Like

Thank you!

The problem with flyctl logs/monitoring for me is that it doesn’t show all prints, and there’s a long delay. I really want to see all the messages that are printed to the console—and instantly, just like you would if you were to run the script locally.

I looked at your link, but I’m not sure which option to use or how to do it, as I’m quite new to this. If you could give me a recommendation for a simple way to just see the messages printed to the console and how I can achieve that, that would be much, much appreciated! I’d prefer not to set up a SQL database, if it’s possible to avoid that.

flyctl logs is the closest to a no-touch solution. Try flyctl logs -r <region-name> or flyctl logs -i <instance-id> to see if you see all logs at least from that region / vm (docs)?

Yeah, me too. I don’t have logging setup on Fly at all (despite using it for various purposes for 20+ months at this point). That said, if logs are critical to your app, then setup fly-log-shipper (I haven’t done so myself, but the GitHub readme seems like a decent enough starting point).

Fly isn’t exactly a no-code solution, but they do aim to be zero-dev-ops (which they aren’t, yet).

1 Like