fly deploy on fresh Laravel app: "The app is not listening on the expected address"

[b18i7k3]

Hello,

I managed to get this working initially and first impressions were decent, but then began experiencing severe performance degradation. After reading and poking around a bit I decided to just start with a totally fresh empty Laravel project with the documentation for a sanity check.

Following the steps at https://fly.io/docs/laravel:

composer create-project laravel/laravel fly-laravel
cd fly-laravel
php artisan serve

The default Laravel boilerplate / landing page appears indeed on http://localhost:8000.

Fly.io account already open and flyctl already installed, so next:

fly launch

The documentation then says:

When asked if you want to deploy now, say No .

However, the next prompt I actually see is this:

$ fly launch
Scanning source code
Detected a Laravel app
Creating app in /home/user/dev/fly-laravel
We're about to launch your Laravel app on Fly.io. Here's what you're getting:

Organization: myuser                                                    (fly launch defaults to the personal org)
Name:         fly-laravel-hidden-water-6964                              (generated)
Region:       Seattle, Washington (US)                                   (this is the fastest region for you)
App Machines: shared-cpu-1x, 1GB RAM                                     (most apps need about 1GB of RAM)
Postgres:     <none>                                                     (not requested)
Redis:        Pay-as-you-go Plan: 10 GB Max Data Size, eviction disabled (determined from app source)
Tigris:       <none>                                                     (not requested)

? Do you want to tweak these settings before proceeding? (y/N)

At this stage it has not yet generated any files in the project dir.

If I say yes, I get the page with options showing internal port 8080 with a message saying that is the recommended default for Laravel apps. I tried with leaving everything as default as well as various changes. Once I hit confirm, I am returned to the cli and see it created app with corresponding admin URL, hostname, set secrets, and then composer require command.

It writes some docker files, .fly directory with fpm, nginx, php/supervisor things and the fly.toml, then builds and push the docker image. IT produces the link to watch the deployment, shows a message about the IPs provisioned and that it will create 2 “app” machines. Then, it has the:

WARNING The app is not listening on the expected address and will not be reachable by fly-proxy. You can fix this by configuring your app to listen on the following addresses:
0.0.0.0:8080
Found these processes inside the machine with open listening sockets:
PROCESS | ADDRESSES
-----------------*--------------------------------------
/.fly/hallpass | [fdaa:a:32f2:a7b:1b6:cfbb:d47:2]:22

It seems like the URL it subsequently provided actually works though. And subsequent fly deploy are again giving me that not listening warning.

When I check the .fly/nginx/sites-available/default, I do see:

listen 8080 default_server;

The fly.toml that I left untouched does have the:

[http_service]
  internal_port = 8080

Is it fine to disregard this warning? Am I just doing this wrong?

Thanks!

[greg]

Hi,

You are doing it all correctly

For the port warning, you are correct in that thanks to:

listen 8080 default_server;
listen [::]:8080 default_server;

… the app is in fact listening on 8080. I assume at that moment in time it isn’t but seconds later, it is. So you can ignore that flash of warning.

As for the …

When asked if you want to deploy now, say No

… again, you are correct. The docs need updating to reflect how the launch command now works. It is much smoother than it used to be.

How it used to work is that you needed to run fly launch initially to tell Fly about the app. That let you then stage a secret APP_KEY (which Laravel needs to run, as a minimum). Then you’d run fly deploy afterwards to get the image built etc. It was a three-step process. Now that can be done all in one go, assigning the APP_KEY as part of the launch.

[b18i7k3]

Hi,

Thank you for confirming that.

I am also seeing latency >10s on cold start, just wondering if this is to be expected.

This is still with a fresh boilerplate (composer command to create new Laravel project and that’s it), so I am assuming ruling out application code as part of the problem is a safe assumption, but I’m still relatively new to these “serverless” things.

I understand there are general trade offs to consider with this type of architecture but please let me know if I should be configuring something differently or how this should usually be approached.

Thanks

(attachments)

[greg]

Hi,

No problem.

10 seconds is a bit longer than expected but yes by default there will be a delay of X seconds if there is no machine already running at the time the request arrives. One needs to be started on-demand and that takes a moment.

It’s not obvious but when you deploy the default is two machines which are set to auto-stop when there are no requests (for a bit). That saves you money (as you’d otherwise be paying for the CPU for an idle machine) but the trade-off is the delay starting when one is needed. You can avoid that delay by having a machine run 24/7 … but the trade-off is you then pay for it. It’s pretty cheap though.

For all the config options, check out:

Autostop/autostart Machines