Combining the Development Dashboard with

Hey! Simon from the Encore team here :wave:

I would like to share something that we are thinking about right now.

TL;DR - We want to combine the local development dashboard and into a one-stop-shop dashboard that contains everything.

How will this work:

  • The local development dashboard and will be the same codebase, residing in the encore repo. This means that we will essentially be open-sourcing all of the application front-end parts of encore.

  • The new one-stop-shop dashboard will be available on localhost after running encore run. All local development features that you are used to will still work offline but when having internet access you will also be able to see your deployed cloud environments. will work as it does today. The local development features will probably be hidden behind a feature flag but we are not sure about that yet.

Why we want to do this:

  • [main reason] We think this will result in a better user experience. By having everything available in the same UI you will be able to compare environments and follow code changes from development to production.

  • We will be able to provide a better onboarding process for new users because everything will be contained in one place.

  • We love the idea that the community will be able to contribute by creating PRs for (almost) all of our front-end UX.

  • Eventually we think it’s a good idea to package the Encore CLI and the dashboard as a native app. This would give us even more tools to enhance the UX. We are not there yet but merging the dashboards is a step in this direction.

These ideas are right now in an early stage and all of this is subject to change.

Would be great to get your thoughts on this. Excited? Concerned? Meh?

1 Like

I’m not sure how integrating the CLI as a native package in encore would “give you even more tools to enhance UX.” But I’d recommend you to keep the CLI separate.

Integrating the dashboard is a good idea :+1:

While you guys are at it, can you also work on a native RBAC feature to protect endpoints?

Also, does this mean that if I encore eject docker then the UI dashboard will also be available with standalone ejected service?

This sounds great, I actually find it a bit confusing now that the web app and the local dashboard look the same. Combining it would mean I could always have the dashboard on one monitor (or iPad with sidecar).

It would be great if you could auto assign different colours to different encore projects and then maybe different icons to the environments. This would help quickly identifying if you’re looking in the right place.

Allowing users to themselves experiment with the layout of the dashboard locally could be great for the community as well, perhaps opening for sharing themes. While the current layout is definitely cool, it does feel a bit catered to appeal to a stereotypical backend dev (male who likes rock music). Some people might prefer pink fluff and rounded corners.

In the end, what I love with encore is that it empowers me and gives me control over cloud technology that would otherwise be quite inaccessible for me (since I’m not an engineer by training). So everything that would help increase this feeling would just make me love it even more. And hopefully make it even more accessible to idea-phase startups.

I think Obsidian is a great example of how this can happen. Started out as quite niche and nerdy, then someone contributed with the minimal theme and all of a sudden it appealed to a much wider user base.


No, at least not in this first iteration. The features in the dashboard are dependent on the many services we’re running and maintaining. Right now it’s not possible to self-host all of this, and I don’t think it really makes a lot of sense (unless you’re an enterprise running everything in-house) given the significant scope of operating this infrastructure. (We’re a full team doing it.)

The encore eject functionality is primarily intended for when you no longer wish to use Encore, to give you an easy migration path. If you do want to use Encore, it’s freely available by simply using your Encore account in the “normal fashion”.

It would be interesting to hear more about why you’re wanting to eject your app and still keep using Encore?

Yes, we feel the same! We just need to figure out how to show the local development features together with the deployed cloud apps. Some interesting interaction design challenges but we will get there.

Do you often switch in between projects? Or when do you feel like this is a problem?

Thanks for the suggestions! We are excited to see how we can involve the community more in the design/UX aspects when all our dashboard stuff in open-source.

1 Like

I do juggle a bit between different projects. We have our core application, but we have now started building out some auxiliary functionality in separate projects as a way to enable people outside the dev team to work on business-related functionality. This lets people on the business side learn Encore and Go without hitting the brick wall of understanding all of the quirks and requirements in our core application.

As an example, I built a CRM in Encore where we try to preprocess some things, and sometimes I want to use some of the endpoints in our core application for this, such as moving a prospect from the CRM into an actual user in our core application. This can be through running both applications locally, both in cloud, or one in each.

That’s super interesting Jakob, thanks for sharing!

What is that brick wall that you’re experiencing? Encore was designed for keeping all such auxiliary functionality inside the same application, so that you get the benefits of simple API calls and such and everything starting up together. Or would that not be useful in this case?

So the brick wall I was referring to is a mixture of things, most of which are not directly Encore-related.

Think of it this way:
We have our core application, which is the responsibility of our dev team. Since it’s client-facing, it has a lot of structures in place in terms of testing, linter etc. We also have a bunch of new features planned, meaning we need to carefully prioritize what the dev team spends time on, since they are the only ones in the company that have the skills to implement them.

But we still have a need for some auxiliary functionality/systems like a CRM, or for example translating a certain agreement into a more functional JSON format. These things are not inherently difficult, and will also not be client-facing. We could of course do what most companies might do, which is give a fat paycheck to a company like Hubspot and then pass around random python scripts and notebooks.

But since Encore is actually quite easy, it seemed preferable to me that we instead let people who are not trained developers learn encore by building these auxiliary systems/functionality as encore apps. This means we don’t have to squeeze these tasks into already crowded sprints and risk diluting our focus. It also means the people on the business side who have the best understanding of e.g. how to represent a client’s operations will be the ones to translate that into code.

In my opinion- it’s not only a great learning experience for the non-developers developing it (you obv feel like a code god when you deploy your first API!), but it actually makes it easier for the dev team to understand the code should the non-developer need some help from the dev team. Should we want to bring it into the core application, that also becomes easier. Of course, it also helps the people building these smaller apps to understand our core application codebase.

Essentially, I think Encore for a great tool to get lightweight biz system backends that can actually really be scaled up as you go. For the CRM I combined it with a low-code frontend framework, but it feels good to know that I could also use it with Flutter if I wanted to have a tiny phone app or even make a complete frontend from scratch.

However, the flip side of this is of course that it means there are multiple encore apps in my workflow at the same time.

1 Like