-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathfly.toml
More file actions
65 lines (56 loc) · 2.14 KB
/
fly.toml
File metadata and controls
65 lines (56 loc) · 2.14 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
# Fly.io configuration for labordata.bunkum.us
#
# Architecture: the Docker image contains only Datasette + plugins + config.
# The actual SQLite databases (~10 GB across 13 .db files) live on a Fly
# Volume mounted at /data and are updated out-of-band via SFTP rather than
# baked into image layers.
app = "warehouse"
primary_region = "iad"
[build]
# Use the Dockerfile in the repo root.
# NB: no [mounts] block.
#
# Volumes are managed entirely by refresh-data.yml — each refresh
# creates a new ephemeral volume (dbs_stage_<run_id>) and the old one
# is destroyed at promotion time. Re-adding `[mounts] source = "dbs"`
# here would make `flyctl deploy` create a second machine attached to
# a brand-new empty 25 GB volume whenever no volume named "dbs"
# exists — which is exactly what happened on the first post-cutover
# deploy and broke the homepage for half the requests.
#
# The mount path is set on each machine at creation time via the
# `flyctl machine run --volume <id>:/data` flag in refresh-data.yml.
[[services]]
protocol = "tcp"
internal_port = 8080
auto_stop_machines = "off" # always-on; we don't want repeated cold-starts
auto_start_machines = true # of the 10GB SQLite mmap working set
min_machines_running = 1 # keep at least one machine up
[[services.ports]]
port = 80
handlers = ["http"]
force_https = true
[[services.ports]]
port = 443
handlers = ["tls", "http"]
[services.concurrency]
type = "requests"
soft_limit = 60
hard_limit = 100
[[services.http_checks]]
# /-/versions.json is constant-time and doesn't touch SQLite. Using
# /-/databases.json instead triggers datasette's per-table inspect scan
# on cold mmap, which on a 10 GB working set blows past any reasonable
# health-check timeout. --inspect-file makes /-/databases.json fast at
# steady state, but the file is uploaded *after* this deploy step, so
# the check has to survive the first boot without it.
interval = "30s"
grace_period = "120s"
method = "get"
path = "/-/versions.json"
protocol = "http"
timeout = "30s"
[[vm]]
size = "shared-cpu-1x"
memory = "2gb"
cpus = 1