Introduction
Setting up bknd
There are several methods to get bknd up and running. You can choose between these options:
- Run it using the CLI: That’s the easiest and fastest way to get started.
- Use a runtime like Node, Bun or
Cloudflare (workerd). This will run the API and UI in the runtime’s
native server and serves the UI assets statically from
node_modules
. - Run it inside your React framework of choice like Next.js, Astro or Remix.
There is also a fourth option, which is running it inside a Docker container. This is essentially a wrapper around the CLI.
Basic setup
Regardless of the method you choose, at the end all adapters come down to the actual
instantiation of the App
, which in raw looks like this:
In Web API compliant environments, all you have to do is to default exporting the app, as it
implements the Fetch
API.
Configuration (CreateAppConfig
)
The CreateAppConfig
type is the main configuration object for the createApp
function. It has
the following properties:
connection
The connection
property is the main connection object to the database. It can be either an
object with a type specifier (only libsql
is supported at the moment) and the actual
Connection
class. The libsql
connection object looks like this:
Alternatively, you can pass an instance of a Connection
class directly,
see Custom Connection as a reference.
If the connection object is omitted, the app will try to use an in-memory database.
initialConfig
As initial configuration, you can either pass a partial configuration object or a complete one with a version number. The version number is used to automatically migrate the configuration up to the latest version upon boot. The default configuration looks like this:
You can use the CLI to get the default configuration:
To validate your configuration against a JSON schema, you can also dump the schema using the CLI:
To create an initial data structure, you can use helpers described here.
plugins
The plugins
property is an array of functions that are called after the app has been built,
but before its event is emitted. This is useful for adding custom routes or other functionality.
A simple plugin that adds a custom route looks like this:
Since each plugin has full access to the app
instance, it can add routes, modify the database
structure, add custom middlewares, respond to or add events, etc. Plugins are very powerful, so
make sure to only run trusted ones.
options
This object is passed to the ModuleManager
which is responsible for:
- validating and maintaining configuration of all modules
- building all modules (data, auth, media, flows)
- maintaining the
ModuleBuildContext
used by the modules
The options
object has the following properties:
basePath
(string
): The base path for the Hono instance. This is used to prefix all routes.trustFetched
(boolean
): If set totrue
, the app will not perform any validity checks for the given or fetched configuration.onFirstBoot
(() => Promise<void>
): A function that is called when the app is booted for the first time.seed
((ctx: ModuleBuildContext) => Promise<void>
): A function that is called when the app is booted for the first time and an initial partial configuration is provided.