Hello,
I am trying to follow the docs on Create a static website on Fly to create a static website. I have cloned the repo as proposed, then generate the fly.toml file using flyctl launch. Finally, the docs mention that I need to run fly deploy. When I run it I get the following:
C:\progr\html\hellostatic-builtin>flyctl deploy
Deploying winter-river-1745
==> Validating app configuration
--> Validating app configuration done
Services
TCP 80/443 ⇢ 8080
Error app does not have a Dockerfile or buildpacks configured. See https://fly.io/docs/reference/configuration/#the-build-section
I understand that a Dockerfile is missing however no Dockerfile is mentioned anywhere in that particular tutorial. So probably the create static website tutorial needs updating (or I am missing something)?
I also tried following the docs to deploy a python website (Build, Deploy And Run A Python Application). This tutorial has exactly the same problem (no Dockerfile). Maybe some configuration is missing to configure fly to use a buildpack instead of docker?
I’m using the latest flyctl version:
(venv) C:\progr\python-hellofly-flask>flyctl version
flyctl.exe v0.0.247 windows/amd64 Commit: 8068b7f BuildDate: 2021-10-11T16:25:15Z
When generating the fly.toml file using flyctl, it’ll usually ask you which builder to use and present you with a list. One of those options should have been a builder called static. Was that the one that was chosen? That should/would have configured your fly.toml to use one of the Dockerfiles managed by Fly.
Hello @sudhir.j thank you for answering. I deleted my fly.toml and run flyctl launch again to display the output:
C:\progr\html\hellostatic-builtin>flyctl launch
Creating app in C:\progr\html\hellostatic-builtin
Scanning source code
Could not find a Dockerfile, nor detect a runtime or framework from source code. Continuing with a blank app.
? App Name (leave blank to use an auto-generated name):
Automatically selected personal organization: Serafeim Papastefanos
? Select region: lhr (London, United Kingdom)
Created app dry-meadow-9284 in organization personal
Wrote config file fly.toml
As you see nowhere it asks for builder! I am using the latest flyctl version.
Hey all! Sorry for the confusion about this. Our docs are wrong - we’ll get them fixed up!
We removed the option to select our internal ‘builders’ because we felt they were not transparent enough. We’d like it to be easy to work from a template and tweak it. That said, we don’t have an official answer yet for static sites.
Builtins should still work, for now, so you add the static one to your fly.toml like this:
To expand a bit on static site hosting: we also have a statics fly.toml section built for this. So Fly would serve your static assets directly without the need for a web server at all.
Are you using a static site generator? If so, which one?
Hello @jsierles thanks for replying. Using the static builder you mentioned worked fine to deploy the static website (https://dry-meadow-9284.fly.dev/), however it doesn’t work with the python-flask example (it pushes all files in the directory and serves them, like this: https://cool-waterfall-513.fly.dev/).
I don’t use any static site generator, I just followed the tutorial.
Could you give me a ping when the python and static docs are updated so I can check again if it works ?
@jsierles For static sites wanting to make use of the statics fly.toml feature, but that don’t have any other dynamic component, i.e. they are 100% static files. What’s the best way to use the statics feature? Should the app still have a Dockerfile that does nothing other than sleep indefinitely?
At the moment how I’m deploying is in an nginx container, so the container can serve the files, but then referencing the files with statics, so in theory the container isn’t doing anything. This seemed like the simplest approach.
It is the simplest approach, yes. The statics feature works great with an application that’s doing other dynamic requests as well, but yeah, it could be used this way. Just a reminder, though, that nginx gives you much more fine grained control over your headers — so if that’s important to you you’re actually better off turning off the statics feature. Any special header values you might be setting in nginx will be lost if statics serves the files instead.
It seems to deploy a Go server for serving static files, but if I visit the deployed server, I don’t see any requests hitting it in the logs. I’m assuming it’s because Fly’s proxy is catching the requests instead, but is there a way of verifying that?
How does Fly’s proxy differ from a regular CDN like Cloudflare?
That seems about right. You should see the requests in your metrics — fly logs are more your application’s logs, and we don’t want to pollute them with static requests that aren’t hitting your application.
How does Fly’s proxy differ from a regular CDN like Cloudflare?
Fly’s statics feature isn’t a pass-through system like Cloudflare — we copy the static directory over to special storage during a deployment, and serve static files from there. URL paths that are not in the static directory do fall-through to the application, but we don’t cache them on the way back out.
Is there a way to skip deploying the Go server and just use the Fly proxy? If my entire app is static files that I want Fly to serve, then it doesn’t seem like the Go server does anything.
There’s not, currently. I think for pure static file hosting, Netlify and friends are a better choice. Most of our features start with the container. What you’re doing will work fine, though, it’s not not what the UX was designed for.
The [[statics]] feature was designed for full stack apps that need to deploy static assets alongside an app server. In your setup, the Go server is the “app server”, it’s just redundant.
Yeah, if we look at Rails or Phoenix or other full-stack frameworks, they all compile CSS & JS into a public or assets folder, served from the same container and referenced on page loads. This usually means that when you load a Rails page you also make between 3 and 30 requests for CSS and JS — all of which the [[statics]] can serve for you without having to hit your application or use its threads or make artificial log entires for.
If the app is a pure single-page-JAM-stack-static only deployment, something like Netlify or Cloudflare Pages will work better because they’ll just copy over the files many edges all over the world on each deploy, without the need for any app servers.
