Skip to content

feat(deploy): enable single-domain routing for one click deployment#1

Open
sivasubramanian95 wants to merge 2 commits into
FlowrabbitStudio:mainfrom
sivasubramanian95:feat/elestio-single-domain
Open

feat(deploy): enable single-domain routing for one click deployment#1
sivasubramanian95 wants to merge 2 commits into
FlowrabbitStudio:mainfrom
sivasubramanian95:feat/elestio-single-domain

Conversation

@sivasubramanian95
Copy link
Copy Markdown

Summary

This PR enables single-domain deployment for Flowrabbit (one-click platform friendly) by switching default routing to path-based rules, while preserving optional legacy host-based compatibility
through an override compose file.

Problem

The previous setup depended on multiple subdomains (api.*, studio.*, proxy.*, apps.*, docs.*) and host-based Traefik routing, which makes one-click deployments difficult.

What Changed

  • Updated default docker-compose.yaml to single-domain path routing:
    • / -> studio
    • /apps -> apps
    • /docs -> docs
  • Added FLR_PUBLIC_URL-based URL composition.
  • Updated app-side URL defaults to support path-based mode.
  • Added docker-compose.local.yaml for localhost override.
  • Added docker-compose.legacy-hosts.yaml for optional host-based compatibility mode.
  • Added .env.example and required env-based secrets in compose.
  • Switched persistent data to named volumes for better cross-platform stability.
  • Updated README deployment instructions.

Validation

  • docker compose config passes for:
    • default mode
    • local override mode
    • legacy-host override mode
  • Local smoke test (Windows):
    • http://localhost/ -> 200
    • http://localhost/api/rest/status.json -> 200
    • http://localhost/docs/status.json -> 200
    • http://localhost/apps -> 200

Compatibility / Notes

  • Single-domain is now the default mode.
  • Legacy subdomain routing is still available via:
    • docker compose -f docker-compose.yaml -f docker-compose.legacy-hosts.yaml up -d

@KlausSchaefers
Copy link
Copy Markdown
Contributor

Have you tried editing in the studio and publishing in /apps?

@sivasubramanian95
Copy link
Copy Markdown
Author

Hey Klaus,

I tested the flow locally (editing in Studio, publishing, and opening the app under /apps). Studio and publishing work, but I noticed that the /apps route is not fully handled in the current PR yet, which can lead to a 404 when opening the published app.

I’ve been debugging the Traefik routing locally and found that the path routers need a few additional adjustments (entrypoints and priorities) for /apps to work correctly in the single-domain setup.

I’m validating the fix locally and will push an update to the PR shortly.

@sivasubramanian95
Copy link
Copy Markdown
Author

Hey Klaus, quick update on the test.

I verified the publish flow locally (Studio → publish → open under /apps). The routing works as expected now:

/ routes to Studio
/apps/<org>/<app>.html loads the apps service
/rest/* and /proxy/* route to backend and proxy correctly

The “debug id is wrong” message I saw in the browser appears to come from the frontend route parsing when loading the published app, not from the routing itself.

If there are any additional scenarios you’d like me to test, please let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants