Description
Docker image for linux/amd64 with cartesi deploy build --platform linux/amd64
-
This command and its utility are currently not referenced in the CLI Commands Page. The only time a dev comes across it is when using the self-hosted deployment method using Fly. A suggested solution is to state its utility in the CLI Commands Reference pages clearly
-
Pushing the amd64 architecture to Fly.io is mandatory when using the Apple silicon Mac. But when you initially build and run
cartesi deploy --hosting self-hosted --webapp https://sunodo.io/deploy, the default is thearm6architecture. This later leads to errors when the user tries to pusharm64to fly.io.
- When does the user run the
cartesi deploy build --platinum linux/amd64? This is ambiguous in the docs. - How does the user inspect the docker image and architecture? Perhaps include
docker inspect image <image-id>in deployment instructions - Troubleshooting tips for when they try pushing the wrong architecture. The typical approach that works is to delete all projects and create new ones with the amd64 architecture, but that's too tedious. Are any quick fixes available?
Fly.io secrets
The current docs recommend setting secrets using the terminal, which can be tricky and deals with copying and pasting stuff in the terminal. Multiple devs reported different experiences using backticks, double quotes, and single quotes.
- A suggested solution will be to add the option of setting secrets interactively on Fly.io on the project dashboard
Production environments
In production environments, how does the user access important APIs like GraphQL, Explorer, and Inspect from their front end? The documentation is now ambiguous about this.
Inputs status
When a user runs into a situation where inputs that were successfully processed on their local device are reporting the UNPROCESSED status after deploying the node, what may be some possible causes and fixes?