Forest is a universal admin interface designed to manage all your application data and business operations. Forest helps developers focus on their product instead of wasting time building and maintaining outdated DIY admin interfaces.
Forest is comprised of an agent (Liana) and a front-end application (UI). Once you install the agent on your app, it will scan your ORM, retrieve the models, and generate an admin REST API that will communicate with the admin UI. Then, when the user logs on to our web app (http://app.forestadmin.com), it queries both the Forest’s server (to get the UI configuration) and your application (to retrieve the data).
Lumber is a CLI that generates an admin interface out of an existing MySQL or Postgres database. You can then start using and customizing your new admin microservice in no time.
Lumber generates the admin REST api automatically based on your database schema. We only host the UI (http://app.forestadmin.com). It is up to you to decide where the admin miscroservice is hosted. It means that your data will never reach our servers. You can test your admin on your local environment with a local database and then deploy it to your production environment.
Everything related to your data or business logic is open source, available freely on our GitHub account.
We host the admin UI. No data from your application ever reaches our servers as requests are initiated directly from your browser, to your application.
Forest is based on a standard REST API. You don’t need to learn any DSL to customize the backend. Moreover, you are free to extend the API for all your particular needs.
The Liana (gem in Rails, package in Node, etc.) you install on your app will analyze the structure of your models and generate a dedicated admin REST API that handles all your common tasks such as CRUD actions, search & filters, sorting, pagination, charts, etc.
Yes. This is exactly what Lumber does: http://www.forestadmin.com/lumber. Lumber generates an ExpressJS admin microservice, isolated from your app.
When installing Forest, it generates a dedicated Admin API which is different from your own APIs in order to make sure Forest works correctly. It is very common to implement your own business logic when it comes to manipulating your data in your database using Forest. Two options are therefore possible:
Regarding your calculated fields used in your API, Forest enables you to reproduce them effortlessly using our Smart Fields features. See our developer documentation here to know how it works: https://doc.forestadmin.com/developer-guide/lumber.html#what-is-a-smart-field
Lumber is a generator that creates an admin microservice after scanning the structure of your database. Forest is an agent that you install directly on your app, where it analyzes the structure of your models. In the end, both generate a REST API that allows you to operate on your data via Forest’s UI.
No, but you can always contact our Enterprise team.
Forest is installed directly within your application (or in the microservice with Lumber). It generates an admin REST API automatically, so that your app can communicate with the UI, that is hosted on our side (http://app.forestadmin.com). It’s the only part of the product that’s on our servers.
We chose this architecture for two main reasons:
Note we can also help you setup a custom DNS to get a legible URL for your end users.
You can start using Forest for Free - see our blog post - and scale your admin features at your own pace.
Our Pro plan gives you access to all our premium features, see our blog post. We charge you based on the number of activities you make on your production environment in your Forest admin interface. This means you will only be charged at the end of the month and based on your level of activity.
Our Enterprise plan is for businesses with specific back office needs requiring dedicated account management and custom setup (SLA, dedicated support, etc.): http://www.forestadmin.com/pricing
Yes. Your’re in the good place if you have an application (in any language) that has a MongoDB database and you would like to have a Forest admin interface built on top. For further details on how to implement Forest on a MongoDB database, see our MongoDB Example.
We’ve developed Lumber, an admin microservice generator that creates for you an admin microservice built to run Forest. For the moment, it’s compatible with any MySQL & Postgres database. Check it out!
We wrote a blog post about this concern. We designed Forest from day one to handle all specific use cases, operations, and business logics. If you have already implemented custom logic to fit your own needs, it will only take a few lines of code to transfer them to Forest and make them available in your admin.
Yes. Each UI configuration is specific to an environment. By default, you run Forest in the dev environment. You can create a new environment in the project settings.
We recommend that each developer have their own development environment.
To deploy a change from one environment to another, you can use the “Copy layout configuration” feature in your project settings -> Environments. We recommend that you first deploy from dev to staging, and then from staging to production.
Yes, Forest is funded and actively maintained. It is used by many teams, including all the projects from the startup studio eFounders. We host the front-end app on http://app.forestadmin.com, so you don’t have to maintain it. We continuously improve upon it. We provide open source packages to install Forest and generate the admin API automatically. They’re all available on our Github account: https://github.com/ForestAdmin
Forest is hosted on your side. We do our best to reduce the number of queries and are constantly working on their optimization (both HTTP and database queries). This way, Forest should use less resources than home-made admins, and is therefore likely to perform better overall than custom-built solutions. You can always isolate Forest in a completely separate part of your app in order to control the scope of your app and your admin independently.
As long as you have data in your database, it is possible to act on them via Forest or display them in a dashboard. If you’re looking for tools to specifically track users’ behavior in your application, Forest will not be fitting. We recommend using tools such as Segment, Mixpanel or Heap for that. That being said, we are working on integrations to feed this data back into your Forest.
User roles determine the access level or permissions of your teammates. Forest Admin allows you to setup three different kinds of users or ‘Roles’.
You can define user roles in your project settings. Go to Settings -> Users and assign roles to each of your teammates.
Yes, you can contact us at firstname.lastname@example.org with the subject of the email set to “Security Issue”.
Yes, all of our open-source projects are hosted on Github: https://github.com/forestadmin. Feel free to review it and post an issue with your questions and feedback.
As you may have noticed, the header HTTP-Strict-Transport-Security (HSTS) is not enforced on our web application. You have the possibility to use app.forestadmin.com through HTTP and HTTPS depending on the Forest environment (e.g. development, staging, production). Very often, your development environment such as localhost:3000 does not have an HTTPS configuration. This is why we make the HTTP protocol available. On a Forest production environment, we highly recommend that you use an HTTPS application endpoint (otherwise you’ll see a warning) to get HTTPS enforced on app.forestadmin.com.
Yes, we regularly use the SSL analyzer SSL Labs to get a full report on our protocols, cipher suites, handshake simulation, etc.
In cryptography, forward secrecy (FS), also known as perfect forward secrecy (PFS), is a feature of certain key-agreement protocols that ensures your session keys will not be compromised even if the private key of the server is compromised.
Our servers are hosted on Heroku which supports a lot of cryptographic features, protocols and ciphers including Perfect Forward Secrecy. More information can be found here and here.
We entirely rely on Heroku (a Salesforce company) for their secure storage.
At the load balancer, hosted on Heroku.
Heroku encrypts the traffic and validates the certificates between their load balancer and application servers.
Yes, we are very careful and have specific controls in place to prevent mixed-content issues.
We use a two-step authentication to connect you to both Forest’s server and your Admin API.
The first step is to retrieve your UI configuration. When logging into your account, your credentials are sent to Forest’s server which returns the UI token to authenticate your session.
The second step is to authenticate yourself on your app to have access to your data. Your password is sent to your Admin API which returns the data token signed by the FOREST_AUTH_SECRET you chose. Each of your requests to your Admin API are authenticated with the Data Token.
In a nutshell, your admin uses the UI token to make requests about the UI configuration. Then the Data Token is used to make queries on your Admin API to manage your data. All of our tokens are generated using the JWT standard.
The main advantage of Forest’s architecture is that absolutely no data transits over our servers. The user accesses application data directly from the client and Forest is just deployed as a service to display and interact with the data.
We use bcrypt, a dedicated password-based key derivation function.
Users self-register and set their passwords online directly within the application.
A the user’s request a password reset link is sent via email to his registered email address.
Head over to http://www.forestadmin.com where you can start the installation process by entering your email and then Get started.
The first one (with email + password) logs you into your Forest account. The second one (password only) authenticates you in your own application so that you can access your data. This process is necessary to keep the promise that Forest will never have access to your data, as the second login generates the token with which every single one of our requests is authenticated.
That’s if you see something like the following in your browser’s console:
Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://app.forestadmin.com' is therefore not allowed access. The response had HTTP status code 404.
That happens when your CORS configuration has been secured to the point that it does not allow our UI to reach your application. To solve this issue, simply whitelist http://app.forestadmin.com and https://app.forestadmin.com in your CORS configuration.
Depending on your stack, you’ll have to run one of the following commands:
$ bundle update --source forest_liana
$ npm install --save forest-express-sequelize@latest
$ npm install --save forest-express-mongoose@latest
Simply run the following command
$ npm install -g lumber-cli@latest
A new version of Forest (2.0.0) has been released on November, 17. Important thing to know:
The admin API generated is protected using a JWT. You can use your own authentication strategy for your app’s API (JWT or not). Both authentication strategies are completely independent.
If you made a clean install of Forest in a separate git commit, you can simply roll back to a previous commit.
Otherwise, you can always uninstall Forest manually: