Service types
workerd supports four types of services:- Worker: A JavaScript/WebAssembly worker
- Network: Network access with address filtering
- ExternalServer: Proxy to a specific remote server
- DiskDirectory: HTTP interface to a local directory
Defining services
Services are defined in theservices list of your configuration:
Worker services
Worker services execute JavaScript or WebAssembly code. See the Workers configuration page for detailed documentation.Network services
Network services define access to networks with configurable address filtering. This is commonly used to define controlled internet access.Network addresses the worker can connect to, in CIDR notation. Traffic is permitted if the address matches at least one entry in
allow and none in deny.Special values:"public": Publicly-routable addresses only (opposite of"private")"private": RFC1918 private networks (superset of"local")"local": Localhost addresses only (127.0.0.0/8, ::1)"network": Any non-local address (opposite of"local")"unix": Unix domain socket addresses"unix-abstract": Linux abstract Unix domain addresses
Network addresses to explicitly block. Takes precedence over
allow.TLS configuration for connections. See Socket configuration for details.
Examples
When a worker specifies a DNS hostname, the allow/deny rules filter the addresses returned by the lookup. If no addresses are permitted, the system behaves as if the DNS entry did not exist.
External server services
External server services forward all requests to a specific remote server. This is typically used to connect to back-end servers on your internal network.Address and port of the server. Can be overridden from command line with
--external-addr <name>=<addr>.Examples:"1.2.3.4": IPv4 address on default port"1.2.3.4:8080": IPv4 address and port"[1234:5678::abcd]:8080": IPv6 address and port"unix:/path/to/socket": Unix domain socket"unix-abstract:name": Linux abstract Unix socket"example.com:8080": DNS hostname
Connect via unencrypted HTTP.
Connect via encrypted HTTPS.
options: HttpOptions for the connectiontlsOptions: TLS configurationcertificateHost: Expected hostname in server certificate (defaults toaddress)
Raw TCP connection. Bindings to this service only support
connect(), not fetch().tlsOptions: TLS configurationcertificateHost: Expected hostname in server certificate
Examples
Disk directory services
Disk directory services expose an HTTP interface to a directory on disk. This is bare-bones and typically wrapped in a worker that adds proper Content-Type headers and other logic.Filesystem path to the directory. Can be overridden from command line with
--directory-path <service-name>=<path>.Relative paths are interpreted relative to the current working directory, not the config file. Use absolute paths in config files.
Whether to support PUT requests for writing files. Uploads are written to a temporary file and atomically moved into place on completion. Parent directories are created as needed.
Whether to allow access to files and directories whose name starts with
.. These are hidden by default since they often store metadata not meant to be served (like .git or .htaccess).The special links . and .. are never accessible regardless of this setting.Example
HTTP interface
GET requests:- Files return with
Content-Type: application/octet-streamandContent-Lengthheader - Directories return JSON directory listings:
[{"name":"foo","type":"file"},{"name":"bar","type":"directory"}] - Possible types:
"file","directory","symlink","blockDevice","characterDevice","namedPipe","socket","other" - Symlinks are followed automatically
- Other inode types return
406 Not Acceptable
- Optimized to perform
stat()without opening the file
writable = true):
- Write to a temporary file, atomically moved on completion
- Parent directories created as needed
Service designators
When referencing services from bindings or sockets, you can use a simple string or a fullServiceDesignator structure:
Name of the service in the
Config.services list.For modules-syntax workers with multiple named entrypoints, this specifies which one to use.
export default is the default entrypoint, while export let foo = {} defines an entrypoint named "foo".Value to provide in
ctx.props in the target worker.empty: Empty object (default)json: JSON-encoded value
Next steps
Workers
Configure worker services in detail
Bindings
Connect services through bindings