Interface: ServerOptions<US>
Defined in: net/server/server.ts:79
A server represents a logical DB with some additional configuration options.
Extends
Extended by
Type Parameters
| Type Parameter |
|---|
US extends Schema |
Properties
| Property | Type | Description | Overrides | Inherited from | Defined in |
|---|---|---|---|---|---|
appName? | string | The application name to use in emails and other user-facing content. If not provided, a default name will be used. | - | - | net/server/server.ts:176 |
buildInfo | BuildInfo | Info about the build process. | - | - | net/server/server.ts:88 |
customConfig? | Record<string, unknown> | Custom configuration to inject into client bundles. Merged with existing GoatDBConfig during static asset serving. | - | - | net/server/server.ts:201 |
debug? | boolean | If true, the DB will be in debug mode. Defaults to false. | - | DBInstanceConfig.debug | db/db.ts:124 |
denoJson? | string | Path to deno.json. Defaults to 'deno.json' inside the current directory. | - | - | net/server/server.ts:117 |
disableDefaultEndpoints? | boolean | If true, disables all default endpoints and middlewares (health, auth, static, etc). | - | - | net/server/server.ts:180 |
domain? | DomainConfig | Configuration for mapping custom domains to organizations and vice versa. This enables multi-tenant deployments where each organization can have its own domain or subdomain. For example: - org1.example.com -> maps to organization "org1" - org2.example.com -> maps to organization "org2" The mapping is bidirectional - domains can be resolved to org IDs and org IDs can be resolved to their domains. | - | - | net/server/server.ts:98 |
emailConfig? | EmailConfig | Configuration for the email service. Can use either SMTP or AWS SES via NodeMailer. Example SMTP configuration (see NodeMailer SMTP docs): { host: "smtp.gmail.com", port: 587, secure: true, auth: { user: "user@gmail.com", pass: "app-specific-password" }, debugEmails: true, // Enable email sending in development from: "system@my.domain.com", } Example Amazon SES configuration (see NodeMailer SES docs): import { SendRawEmailCommand, SES } from "npm:@aws-sdk/client-ses"; { SES: { ses: new SES({ region: "us-east-1" }), aws: { SendRawEmailCommand }, }, debugEmails: true, // Enable email sending in development from: "system@my.domain.com", } | - | - | net/server/server.ts:151 |
fetchUserByEmail? | (db, email) => ManagedItem<US, Schema> | Promise<ManagedItem<US, Schema>> | A hook that's used during email-based authentication flows to look up or create users. This function is called when a user attempts to log in with an email address. Implementing this hook allows you to: - Integrate with external user management systems - Implement custom user lookup logic - Lazily create users when they first authenticate - Apply organization-specific policies for user creation If not provided, the system won't handle email-based authentication and authorization. | - | - | net/server/server.ts:168 |
https? | { cert: string; key: string; } | { hostname?: string; selfSigned: true; } | HTTPS configuration for secure connections. When provided, the server will use HTTPS with the specified certificate. If selfSigned: true, a temporary self-signed certificate will be generated. | - | - | net/server/server.ts:186 |
logStreams? | LogStream[] | Optional array of log streams. All of the server binary's outputs will be directed to these streams. | - | - | net/server/server.ts:109 |
mode? | DBMode | The mode of operation for this database instance. | - | DBInstanceConfig.mode | db/db.ts:86 |
orgId? | string | Optional organization id used to sandbox the data of a specific organization in a multi-tenant deployment. Defaults to "localhost". | - | DBInstanceConfig.orgId | db/db.ts:91 |
path | string | The directory under which all server data will be stored. This includes database files, logs, and other persistent data. | DBInstanceConfig.path | - | net/server/server.ts:84 |
peers? | string | Iterable<string, any, any> | Absolute URLs of peer nodes to sync with. This option is only used for server cluster configurations, where multiple server nodes act as a single logical node in the network, sharing the same root session and cryptographic keys. In a server cluster, all peers listed here must share the same public/private root keys, and will coordinate as one logical entity. For client applications, this argument is not needed—React hooks and the client library automatically set up communication with the server as required. | - | DBInstanceConfig.peers | db/db.ts:104 |
port? | number | The port the server will listen to. Defaults to 8080 (HTTP) or 8443 (HTTPS). Note: When using port: 0 (OS-assigned port), provide a custom domain config, as the default resolveOrg captures the port at construction time. | - | - | net/server/server.ts:104 |
registry? | DataRegistry | Optional schema registry to use for this database instance. If not provided, the default global registry (DataRegistry.default) will be used. The registry contains all schema definitions and authorization rules that this database instance will work with. Authorization rules define who can read, write, or delete data based on user permissions and data properties. | - | DBInstanceConfig.registry | db/db.ts:119 |
staticAssets? | StaticAssets | Compiled static assets the server will serve. | - | - | net/server/server.ts:113 |
trusted? | boolean | If true, all security mechanisms are bypassed in favor of speed. Set this to true when running purely in a trusted backend environment. Defaults to false. | - | DBInstanceConfig.trusted | db/db.ts:110 |