Roadmap

Add skeleton loaders using React Suspense, Promise.all, and React.use() to the entire onboarding flow. This will improve the speed and user experience by displaying loading placeholders while data is being fetched, resulting in a smoother, faster process for users

• Check the user added the records in the register or not

1. Make dflow deployable via DockerFile
2. This helps dflow deployable anywhere and we can provide support for installation on same server

After creating the security group, allow the user to select it during onboarding.

Implement an AWS Connect button to authenticate the user and save their details. This ensures some users won't need to directly provide their secrets. Explore OIDC (OpenID Connect) compatibility with Vercel and Railway for authentication.

When a new security group rule or tag is added, it currently appears at the bottom of the list. This can make it hard for users to verify their recent additions. Update the UI logic so that newly added items (rules or tags) are inserted at the top of the list for better visibility and user experience.

Expected Behavior:

• Newly added inbound/outbound rules should appear at the top of the rule list.
• Newly added tags should appear at the top of the tag list.

UI

1. Add xterm for all terminals
2. Use xterm write to directly perform operations on DOM level
3. This will improve the terminal performance

Objective:

Eliminate the need for customers to have a Railway account to deploy the dFlow app.

Steps:

1. Customer buys a VPS from a cloud platform.

2. Run the shell script on the VPS to deploy the following:

   • dFlow app (from the GitHub repo)
   • Redis
   • MongoDB

3. Accessing the deployed app:

   • The customer will need either an IP address or a domain to access the application.

4. Onboarding process:

   • On first access, the local server (master) will be automatically created.
   • Slave servers will be set up during the process.

5. Project and server creation:

   • Customers can create projects and servers using the local server (master).

6. Old architecture logic:

   • The remaining logic will follow the same structure as the previous architecture.

Tasks:

1. Install dFlow on VPS:

   • Deploy and utilize dFlow on the same VPS.

2. Install dFlow as a Master Service:

   • Deploy dFlow on a VPS, making it the master, and then create services on slave nodes.

UI Changes

1. Add select option for deploying public git-app's, docker-images

Backend Changes

1. Make github-account option as optional
2. Make railpack, dockerFile queue deployment compatible

Backend changes

• move the environment-variables from json field to key-value based schema
• add linked services field and store the linked database details in that field

UI Changes

• add reference variables (same service can be linked to multiple variables)
• show the un-saved changes in the button field

• When switching tabs, the page loads quickly and the skeleton appears while the data is being fetched.
• However, when opening a server, the page takes longer to load. The progress bar is shown first, then after the page load, the skeleton appears, and finally the UI is rendered.
• Ideally, the skeleton should be displayed immediately while the data is loading, instead of waiting for the full page load.

Summary:

Introduce a contextual documentation sidebar to provide inline, non-blocking help throughout the dFlow application. This will improve the user experience by offering just-in-time documentation access via info buttons placed near key UI components (e.g., onboarding process, deploy button, S3 backup toggle). The sidebar should be non-modal, allowing users to continue interacting with the main UI while the documentation is open.

Background & Motivation:

As dFlow grows, users (especially new ones) may encounter confusion when interacting with deployment flows, environment variables, backup settings, etc. A lightweight, always-accessible help system is needed to reduce friction and support self-serve onboarding — without redirecting users to an external documentation site or blocking their interaction.

We want to keep the experience clean, contextual, and embedded into the app.

Feature Requirements:

• Place info buttons near relevant UI components (e.g., buttons, toggles)
• Clicking an info button should open a right-side
• The sidebar must:
  • Not overlay or block the main UI
  • Be fixed-position on the right side of the screen
  • Be dismissible (close button)
  • Pull content from existing content collection docs (based on a slug/key)
• Docs should support markdown/MDX (rendered using existing content pipeline)
• User should be able to interact with the main app even when the sidebar is open

Implementation Details:

• Build a lightweight custom sidebar (avoid using shadcn/ui Sheet due to its modal overlay nature)
• Suggested tech stack:
  • framer-motion for slide-in animation
  • TailwindCSS for layout/styling
  • Use MDX content from the content/docs collection
• Info buttons should pass a unique slug or docId to open the correct help entry
• Render content dynamically (lazy-load or preload)
• Consider wrapping the sidebar in a shared layout component for global access

• Introduction
• Architecture
• Installation
• Server
• Git Sources
• AWS
• Security Groups
• Onboarding