I'm creating this feature request to make Retool compatible with ARM architectures. It would be useful for running it on Apple new MacBook using the M1 chip and for the Raspberry Pi 4.
Hey folks! Brand new Retool team member here. I just onboarded yesterday (9/6/2022) and was just able to set up a fresh M1 MacBook Pro with the latest Retool Docker image(s) per the documentation. If people were having trouble running on an M1 Mac previously, it might be time to give it another go. There is more context in the docs, but the steps I just followed were:
Hi,
should it be running on a raspberry pi (3or4)as well?
I am using portainer.
[retool-onpremise_db-connector_1]:running
retool-onpremise_db-ssh-connector_1: running
retool-onpremise_postgres_1: running
Log says for both:
exec /usr/local/bin/docker-entrypoint.sh: exec format error
After installaing I have seen this in the terminal:
Retool was installed in ~/retool. It will run in the background until you manually stop it. If Retool stops you can restart it without losing your data.
/usr/bin/open: 882: www-browser: not found
/usr/bin/open: 882: links2: not found
/usr/bin/open: 882: elinks: not found
/usr/bin/open: 882: links: not found
/usr/bin/open: 882: lynx: not found
/usr/bin/open: 882: w3m: not found
xdg-open: no method available for opening 'http://localhost:3000/auth/signup'
in the dir there seems not to be a docker-entrypoint.sh
pi@raspberrypiintern:/usr/local/bin $ ls
docker-compose dotenv jsonschema normalizer pycache wsdump.py
Hey @ziza! Ooh, great (and tough) question. I'm not sure we have any success stories with Raspberry Pis (that I know of), but happy to dig into this with you. Would you mind sharing a bit more about your use case?
Hey Felix! I brought this up in a couple team meetings and it doesn't seem like I have any promising leads to offer you I have heard rumors of users being able to deploy on a Raspberry Pi and a team member actually tried over the weekend, but no luck yet. For now, I'll create a feature request for explicit Raspberry Pi support and will connect it to this thread internally! For anyone reading this that HAS successfully deployed, definitely let us know!
I just tried to set up Retool Self-Hosted on my MacBook Air M1 2020 with Docker and it just doesn't work. Firstly, the web app itself needs about 10 minutes before it comes online and responds to requests. Once it's online, navigating from page to page is really slow and laggy, almost to the point of being unusable. Secondly, for some reason the db-connector services seem to constantly crash and restart themselves.
For now the only way I can figure out how to do local development is to use ngrok to open a tunnel to the database server running on my machine, and then use Retool's cloud hosted product with that. It's not ideal since each time I turn on ngrok I need to reconfigure my database connection in Retool, but I suppose this will work for now.
This is my first time using Retool and I gotta say it's not off to a great start. Hopefully improvements to local dev experience are coming soon.
Hey @benknight! Ack, that doesn't sound ideal. Are you still running into this? If so, would you be able to send your api container logs? Should be with a command like this:
Follow up - I think this may be a Docker for macOS issue. Shutting down containers for other apps seems to solve the crashing/restarting issue with the db-connector and db-ssh-container Retool containers.
Hi there, first time trying Retool on-premise here.
I'm still having issues running the app on M1 via Docker. The images are not compatible with the host platform on MAC M1 (linux/arm64/v8), and are thus always crashing and restarting.
Do you have any plan to support MAC arm64?
Otherwise, do you have other solution to enable development on local machine with Retool ?
I'm looking into this internally. Our engineering team is looking into supporting arm64 on-prem images. It's something we want to support in the future, but don't currently have a timeline for. We'll let you know when we're able to ship something.
In regards to still deploying Retool in the meantime, it does seem that several users have still been able to deploy Retool locally on an M1. It would be helpful for us to investigate any error messages you're seeing, as well as confirm the exact steps you've taken so that we can try to reproduce & escalate this issue internally. I'd echo Kabirdas' questions on this thread.
-Would you mind sharing your container logs as well? If you have a larger zip file you're welcome to reach out to us directly via chat or email.
-Are you using a one-line deploy script?
Also, what does it say when you hover over !AMD64 ?
I'm also facing similar issues being unable to deploy and run locally on M1.
please let me know if you need my logs and if so - exactly what you require and where to send them to please.
If you can share the api container logs, we can read through them (feel free to message me directly). That said, I just connected with a user that was able to deploy locally on an M1 only by using these docs (the instructions are a bit more up to date than the ones on my.retool.com) and having their default platform set to linux/amd64
Here is a very dodgy, but apparently working way to get retool running natively on arm (tested on m1 max). Requires retool 3.x as the terrible encrypted node package thing is gone.
FROM tryretool/backend:3.4.6 as retool
# amd64 build
FROM retool as build-amd64
# arm64 build
FROM node:16-bullseye as build-arm64
# no openjdk-11-jdk on bookworm
# install dependencies (replace jre with jdk to allow java node dep to build)
RUN apt-get update && apt-get install -y curl unzip wget openjdk-11-jdk gosu tini iptables procps dnsutils libaio1 libpq-dev libssl-dev tdsodbc
ENV APP_ROOT=/retool_backend
ENV PATH=/retool_backend/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# copy the built application
COPY --from=retool /node_modules/ /node_modules/
COPY --from=retool /package.json /package.json
COPY --from=retool /yarn.lock /yarn.lock
COPY --from=retool /retool_backend/ /retool_backend/
COPY --from=retool /retool_frontend_serverside/ /retool_frontend_serverside/
WORKDIR /retool_backend
# override a few of the dependencies, that have a native component
# retool uses nodegit@0.28.0-alpha.11 - but 11 wont build on arm
RUN mkdir temp && cd temp && npm init --workspaces=false -y && \
npm install lz4@0.6.5 nodegit@0.28.0-alpha.12 java@0.12.2 && \
cp -R node_modules/lz4 node_modules/nodegit node_modules/java /node_modules
# create the user/group and set the file permissions (from the official image)
RUN mkdir -p /home/retool_user \
&& groupadd --gid 999 retool_user_group \
&& useradd --system --uid 999 --gid retool_user_group retool_user \
&& chown retool_user:retool_user_group --recursive /home/retool_user \
&& chown retool_user:retool_user_group --recursive /root \
&& chown retool_user:retool_user_group --recursive /retool_backend \
&& chmod --recursive a+rwX /home/retool_user \
&& chmod --recursive a+rwX /root \
&& chmod --recursive a+rwX /retool_backend
RUN chown retool_user:retool_user_group ${APP_ROOT} \
&& chmod 777 ${APP_ROOT}
USER retool_user
ENTRYPOINT ["/retool_backend/docker_scripts/start_api.sh"]
# final image
FROM build-${TARGETARCH}
NOTE: This apparently 'works' enough for us, but I haven't even tried to get the oracle or sap hana drivers etc to work.
For enterprise, add -enterprise to the image. And you can change the entrypoint to start_enterprise.sh, but we didn't and it still worked.
Hopefully this gets officially supported at some point, it's loads quicker and uses much less ram.
BTW the official 3.x image works only with rosetta using OrbStack, and only without rosetta on official Docker for Mac.