Troubleshooting¶
Common problems with Flowise, what causes them and how to fix them.
The UI does not load right after launch¶
Cause: Flowise loads all of its components before it answers. On first boot, or after a restart, that can take around five minutes.
Fix: wait, then check:
Sign-in fails with the password from the file¶
Cause: the owner account is created only after Flowise first answers. If
sushi-flowise-admin has not finished, or failed, the account does not exist
yet.
Fix: check the unit, read its log, and retry it:
systemctl is-active sushi-flowise-admin
sudo journalctl -u sushi-flowise-admin --no-pager
sudo systemctl restart sushi-flowise-admin
The browser warns about the certificate¶
Cause: the certificate is self-signed for this instance.
Fix: compare the fingerprint, see Open the builder, or install your own certificate, see Replace the TLS certificate.
Connection refused on localhost:8443¶
Cause: the port-forwarding session is not running, or forwards a different port.
Fix: start the session again with portNumber and localPortNumber set
to 8443, and keep it open while you use Flowise.
Uploading a document fails with HTTP 413¶
Cause: the file is larger than nginx's 50 MB request limit.
Fix: raise the limit, see Raise the upload limit.
A flow fails when it calls the model¶
Cause: the credential is missing or wrong, the instance cannot reach the provider over outbound HTTPS, or, for Bedrock, the instance role does not allow the model.
Fix: check the credential in Flowise, the security group's outbound rules and the instance role, then read the Flowise log:
Flowise or nginx does not start after first boot¶
Cause: the first-boot service failed, so the services that depend on it did not start.
Fix: read the reason, then start the units in order:
sudo journalctl -u sushi-flowise-firstboot --no-pager
sudo systemctl restart sushi-flowise-firstboot
sudo systemctl start flowise nginx sushi-flowise-admin
If it still fails, contact info@softwaresushi.com.
Last updated October 13, 2026 · Suggest an improvement