Have you ever successfully deployed a remix.js app using the indie stack? What's your secret

I can’t for the life of me figure out how to get a remix app deployed. I spend many hours trying to deploy my app with the DnB stack and failed so I switched to indie in hopes of better results. I made a bug report: Initial commit will not deploy · Issue #278 · remix-run/indie-stack · GitHub

This stack seems to need some love. It’s the instructions are using the create command which was deprecated years ago.

Assuming that you have committed your changes, can you try:

npx --yes @flydotio/dockerfile@latest --force

… and tell me if the Dockerfile works?

1 Like

It can’t get the proper app name so I get

 force  Dockerfile
     create  docker-entrypoint.js
Error: Could not find App "undefined-staging"

I was on main so it didn’t detect the environment right either.

So then I hardcoded the app name, on both envs and pushed out the dockerfile changes. I had to tell eslint to ignore it.

The deploy purportedly succeeded but the app just hangs indefinitely: ignore entrypoint · justin-hackin/test-indie-stack@637d46e · GitHub

I did some more research and found this

root@5683d551b36518:/myapp# printenv DATABASE_URL
root@5683d551b36518:/myapp# ls /data

So this line in the dockerfile was suspect:

ENV DATABASE_URL=file:/data/sqlite.db

I tried changing it to file:/myapp/dev.db because that file actually exists inside the docker container. But alas, that didn’t solve my problem either.

I encounted this error so I changed the vite port to 8080.

Now I’m back to the health check failing :confounded:

So then I got thinking: why is dev.db in the root myapp? I looked in /myapp/prisma and there’s also a dev.db file there :exploding_head: Y tho? I changed the db url to point to it but that didn’t do anything for me either.

For context, I have successfully deployed a remix app (just a demo, so nothing complicated) using both the Dockerfile provided by the indie stack and the one that we will generate using either fly launch or the dockerfile generator. I also see from our logs that other people have successfully run fly launch with remix applications.

And while I know fly and dockerfiles and node, my knowledge of remix is limited and my knowledge of your app is zero.

With that out of the way, if you are using sqlite3, you will want the database to stay around between deploys, so you will want it on a volume. /data/ looks right and you finding lost+found there is also a good sign as such directories are created on each new volume.

Assuming that your prisma/schema.prisma contains:

datasource db {
  provider = "sqlite"
  url      = env("DATABASE_URL")

The next step is to verify that the startup of your server causes the following to be run:

npx prisma migrate deploy

What do the ENTRYPOINT and CMD look like in your Dockerfile? What script do they run, and does that script run the command listed above?

Okay, I’m more of a frontend dev so I was a bit confused about persistent storage but I came to understand that I do have a volume named data and it is getting mounted in the data dir. Note that the example I’m using is public so you can take a look at the dockerfile here: test-indie-stack/Dockerfile at main · justin-hackin/test-indie-stack · GitHub .

On thing I noticed about the dockerfile from npx --yes @flydotio/dockerfile@latest --force is that it had 3 slashes following file: and everywhere else only had 1 so I changed it but that didn’t help either. The entrypoint file can be seen here: test-indie-stack/docker-entrypoint.js at main · justin-hackin/test-indie-stack · GitHub and I added a log that confirms that migrate is running in entrypoint but it doesn’t show up anywhere I guess because it’s outside the docker container.

However, I was able to confirm that the bad db url was the source of problem because I see

2024-04-01T13:52:10.496 app[9080e339b75748] yyz [info] Prisma schema loaded from schema.prisma

2024-04-01T13:52:10.502 app[9080e339b75748] yyz [info] Datasource "db": SQLite database "sqlite.db" at "file:/data/sqlite.db"

2024-04-01T13:52:10.545 app[9080e339b75748] yyz [info] 1 migration found in prisma/migrations

2024-04-01T13:52:10.548 app[9080e339b75748] yyz [info] No pending migrations to apply.

However, the app still didn’t work because of an invariant error. It didn’t print the env var but it was obvious from the code I forgot to add a SESSION_SECRET. Adding it, the app still hangs.

Finally, the fly.toml file had the wong internal port so I set it to 3000.

2024-04-01T14:20:15.573 app[9080e339b75748] yyz [info] > start

2024-04-01T14:20:15.573 app[9080e339b75748] yyz [info] > remix-serve ./build/index.js

2024-04-01T14:20:15.974 app[9080e339b75748] yyz [info] [remix-serve] http://localhost:3000 (

2024-04-01T14:20:16.066 proxy[9080e339b75748] yyz [error] failed to connect to machine: gave up after 15 attempts (in 8.156592822s)

I was pretty confused about the port mapping (80) to the internal port so I added :80 to the app url and the app actually showed up instead of the connection hanging :open_mouth: So then I noticed the fly.toml was forcing https and I assumed the project wasn’t supporting that since it didn’t even have a vite config. Setting both of the force_https in the file to false solved the issue. Thanks a lot for your support @rubys . It meant a lot because this has been one of the most frustrating devops experiences I’ve ever had with a basic example setup.

Cool. Now that you have it working, you should be able to enable https as that is something that fly.io will automatically take care of for you, if you configure it correctly in your fly.toml.

1 Like

I discovered that sometimes when I triggered a deploy there was seemingly some stale data in the cache. I believe this is the case because I see

371f249cb37b: Mounted from [name of another app from another repo that I last deployed]

After seeing that, I noticed that the db file isn’t in the volume.

I just triggered another deploy and then I didn’t see the other project name in the docker logs and the db showed up in /data

These deploys seem really flakey. One time I only just changed the prisma schema to use the DATABASE_URL env var and the building of the images fails:

Waiting for remote builder fly-builder-delicate-morning-2685...
Remote builder fly-builder-delicate-morning-2685 ready
Error: failed to fetch an image or build from source: Get "http://fdaa:9:cc4:a7b:ef:1425:7442:2:8080/flyio/v1/extendDeadline": connect tcp [fdaa:9:cc4:a7b:ef:1425:7442:2]:8080: connection was refused
Error: Process completed with exit code 1.