I deployed the default Fresh application with a few minor modifications to the default Dockerfile and fly.toml generated by fly launch.
A strange phenomenon occurred when the scale count was 2 and I went to see the URL where the application was hosted.
It resulted in multiple browser reloads and random 404 errors.
Fresh’s Counter button does not work due to the 404 being raised.
As I was thinking about what to do, I realized some more interesting things.
First of all, this problem is that it will work normally after about 10 minutes. And apart from that, with a fly scale count 1 everything worked fine right after I deployed! It was interesting.
What should I do to ensure stable behavior even when deployed with a scale count of 2 or higher? Below is the Dockerfile and fly.toml. Also, the application
deno run -A -r https://fresh.deno.dev
I’m just taking advantage of the default configuration generated by
Here is my Dockerfile and fly.toml
# Based on https://github.com/denoland/deno_docker/blob/main/alpine.dockerfile
FROM denoland/deno:bin-1.36.4 AS bin
RUN apk --no-cache add ca-certificates \
&& addgroup --gid 1000 deno \
&& adduser --uid 1000 --disabled-password deno --ingroup deno \
&& mkdir /deno-dir/ \
&& chown deno:deno /deno-dir/
ENV DENO_DIR /deno-dir/
ENV DENO_INSTALL_ROOT /usr/local
COPY --from=bin /deno /bin/deno
RUN /bin/deno task build
# fly.toml app configuration file generated for test-uyas on 2023-09-07T00:00:51+09:00
# See https://fly.io/docs/reference/configuration/ for information about how to use this file.
primary_region = "nrt"
app = "task preview"
internal_port = 8000
force_https = true
auto_stop_machines = true
auto_start_machines = true
min_machines_running = 0
processes = ["app"]
If none of this helps at all, hopefully someone else who understands this better than I could help answer your questions. It is definitely odd that scaling the count to 2 or higher brings issues. I’m going to keep digging, and if I find something new, that would be helpful, I’ll be sure to post it here.
Sorry, may I ask what version of Fresh you ran here?
When I reported this phenomenon, the version was @1.4.2, and @1.4.3 was released about a day ago!
I changed to the 1.4.3 version on my device and then deployed it again, and the 404’s no longer occur. Perhaps this is now a possible issue on the Fresh side. If the anomaly is reproduced with 1.4.2 and not with 1.4.3, it is definitely caused by fresh…