How to Deploy Appsmith Internal Tool Platform

Appsmith is an open-source platform for building internal applications — dashboards, CRUD admin panels, support tools — by dragging widgets onto a canvas and binding them to queries against your databases and APIs. It's a strong alternative to Retool for teams that want to self-host. This guide covers a clean production deployment.

Architecture

Appsmith bundles its components but you should understand them:

The canonical self-hosted image (appsmith/appsmith-ce) packages these together with an embedded MongoDB and Redis for convenience. For production, you should externalize MongoDB and Redis so your data survives container restarts and can be backed up and scaled.

Externalize the stateful pieces

Point Appsmith at external MongoDB and Redis via environment variables:

APPSMITH_MONGODB_URI=mongodb://user:pass@host:27017/appsmith
APPSMITH_REDIS_URL=redis://host:6379
APPSMITH_ENCRYPTION_PASSWORD=long-random-secret
APPSMITH_ENCRYPTION_SALT=long-random-secret

The embedded databases inside the all-in-one image live on the container filesystem — fine for evaluation, dangerous for production. On PandaStack you can attach a managed MongoDB and managed Redis and point these variables at them.

The encryption keys are critical

APPSMITH_ENCRYPTION_PASSWORD and APPSMITH_ENCRYPTION_SALT encrypt the credentials Appsmith stores for your datasources — the passwords to your production databases and the API keys to your services. If these change, Appsmith can no longer decrypt saved datasource credentials and you'll have to re-enter every connection. Set them once, store them as secrets, and never rotate casually.

Connecting datasources

The whole point of Appsmith is binding UIs to data. After deploy, add datasources from the editor: PostgreSQL, MySQL, MongoDB, REST, GraphQL, and more. A common pattern is to build an internal admin panel over a PandaStack managed PostgreSQL that also powers your main app. Use a read-replica or a scoped database user for Appsmith where possible, so an internal tool can't accidentally run destructive queries against production.

-- a least-privilege user for Appsmith
CREATE USER appsmith_ro WITH PASSWORD '...';
GRANT CONNECT ON DATABASE app TO appsmith_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO appsmith_ro;

Email, SSO, and access control

For a team deployment, configure SMTP so Appsmith can send invitations and password resets (APPSMITH_MAIL_* variables). Appsmith supports SSO (OIDC/SAML) and granular access control — wire these up before onboarding the team rather than after. Restrict signups to your domain with APPSMITH_SIGNUP_ALLOWED_DOMAINS.

Backups

Because apps and datasource config live in MongoDB, your backup strategy is a MongoDB backup. Schedule a mongodump to object storage on a cronjob. If you used a managed MongoDB, you also get scheduled and manual backups at the database layer.

Go-live checklist

• External MongoDB + Redis (not embedded)
• Encryption password/salt set as stable secrets
• Least-privilege datasource users
• SMTP configured for invites
• Signup domain restriction or SSO
• Scheduled MongoDB backup

References

• [Appsmith self-hosting docs](https://docs.appsmith.com/getting-started/setup)
• [Appsmith configuration / env vars](https://docs.appsmith.com/getting-started/setup/instance-configuration)
• [Appsmith datasources](https://docs.appsmith.com/connect-data/reference)
• [Appsmith GitHub](https://github.com/appsmithorg/appsmith)

Appsmith runs as a PandaStack container service with managed MongoDB and Redis attached, and your existing managed PostgreSQL is one datasource away from a polished internal admin panel. Start on the free tier at [dashboard.pandastack.io](https://dashboard.pandastack.io).