I’m experiencing the same issues as nate - my apps cannot resolve the internal hostname (Phoenix/Elixir app with Ecto); I’ve tried detaching, reattaching (there was a 500 in there also), deleting and recreating the apps to no avail.
Also, yes - the experimental private_network setting is enabled in fly.toml for the app.
I split this out into its own topic because we’ve hit it a few times!
Getting Phoenix going is harder than it should be right now. You need to enable IPv6 in your app to get it to work. You might also need to disable SSL. The config should look something like this:
# Configure your database
config :chat_api, ChatApi.Repo,
url: database_url,
show_sensitive_data_on_connection_error: true,
pool_size: 10,
socket_options: [:inet6],
ssl: false
The DATABASE_URL secret uses the postgres:// scheme but it seems ecto needs the ecto:// scheme. Could you see if it works after updating that?
*Edit: I’ve had it work with postgres:// but just yesterday saw an app unable to connect unless it was ecto://. I haven’t dug into it further though.
socket_options: [:inet6] did the trick, thanks!
We just discovered that might break ipv4 database connections if you’re running the app elsewhere. If you run the app on Heroku with the same config, you might need socket_options: [:inet, :inet6].
Btw, the Postgre instance isn’t exposed outside of the external network, correct (which is the desired behaviour IMHO) - specifically since Fly does not allow exposing ports other than 80, 443, 5000 and 10000-10100? Is that correct?
Also, two unrelated questions, but didn’t want to open a separate topic:
8,436,960 seconds per month / Run 3 shared-cpu-1x VMs full time.
But shared-cpu-1x has three price tiers, based on allocated RAM - so how is that calculated? Does it mean 3 free nodes with 256MB and pro-rated amount of 1GB free nodes (1.09 nodes)? Also, in the developer docs, it is not specified whether fly scale memory accepts an arbitrary amount/megabyte input or only the predefined ones from the pricing page (256, 1024, 2048)?
P.S: Also, to add 2 more cents, I think the default grace_period should be slightly increased, I’d imagine most apps can take a bit to startup (not just talking Elixir, but any)…and from my experience it was not immediately clear that this was causing the failure of the deployment (could be better documented). And also should probably be documented that there seems to be a hard limit of 120s for the grace_period? This becomes noticeable if you do any heavier tasks (or build tasks) as part of the CMD directive in the Dockerfile instead of RUN (despite this being a bit of an anti-pattern, it is quite frequent)
Correct, it’s only accessible on the same private network.
Not right now.
I can’t remember how we calculate billing for memory, paging @kurt
We’ve gone back and forth on this and found 1s to be a reasonable default for most apps. Since the grace period is a floor for how fast a VM can start we don’t want it slow by default.
We charge for extra memory, $5/GB prorated. Running VMs in the free tier means you only pay for the additional memory you add.