Local development
On Node.js the service runs from one command: cds watch compiles the model, creates the database artifacts as it goes, mocks the imported services and accepts the pre-defined mock users. What a developer adds to that is the router in front of it and a binding to a service in the cloud.
Showing artifacts, examples and content with confirmed Node.js applicability. View All CAP
Overview
cds watch watches for changed files and restarts the Node.js server, and the artifacts a SQLite database needs are created as it runs, so a Node.js project needs no build step to prepare one. Authentication is the mocked strategy, basic authentication with the pre-defined mock users @sap/cds ships, and an imported remote service is mocked without being asked.
Not covered: Mocked authentication is not suitable for production, so what a local run settles about authentication stops at the mock, and a mocked service returns no data across its associations until the imported model is extended by hand. The in-memory database is reset on each application start, so nothing a run writes outlives it.
dev-approuterdev-approuterA development-time wrapper for the SAP Application Router that serves UI5 and CDS modules once they are added to the project as dependencies.community org, cap and @neoimpulse/cap-js-bootstrap@neoimpulse/cap-js-bootstrapA command-line tool that starts a local CAP environment with several services and an AppRouter together from one command, documented in German and requiring Node 22 or newer.independent, cap start the router, the second with several services behind it, and the local HTML5 repository of @cap-js-community/common@cap-js-community/commonSix independent features for CAP services in one package: replication cache, migration check, rate limiting, a Redis client broker, a local HTML5 repository and a CDM builder.community org, cap serves the apps in the app folder from the file system.
Artifacts
Tasks
Open a CAP application through its router locally
A developer opens the application on a laptop at the address the App Router serves, logs in through the real authentication flow, and reaches the CAP service and the UI modules behind it the way a deployed request would.
Covers the routing and the login in front of the service. Starting the service itself is a separate outcome, and so is resolving the cloud bindings the router's authentication needs. Assessed on Node.js, where capire documents the local App Router setup; the same router in front of a CAP Java service was not assessed here.
@sap/cds-dkcds add approuter puts the router in the project, and cds bind --exec -- npm start starts it on port 5000 with the credentials of the bound XSUAA instance, with the service running beside it under the hybrid profile.
Conditions: an XSUAA or SAP Identity service instance exists in the cloud and is bound with cds bind, since the credentials the router starts with come from that binding the CAP application runs beside the router with the hybrid profile
Remaining work: Create the service instance and the service key in the cloud, bind them, and keep two processes running. The router itself needs no restart on a file change, since it serves static files or delegates to the backend service.
@cap-js-community/commonServes the apps and libraries of the project's app folder from the local file system as the HTML5 repository the router asks, and proxies every other request to the remote HTML5 repository, so a UI change is tested behind the router without being deployed first.
Conditions: a default-env.json in the approuter folder holds a valid HTML5 repository configuration from the deployment environment the app or library sits in the app folder and contains a ui5.yaml, which is what the local repository picks up
Remaining work: Write the configuration file and run the local-html5-repo command beside the router. The package is a bundle, so depending on it for this one feature brings its other five.
@neoimpulse/cap-js-bootstrapStarts a local CAP development environment of several services together with the App Router: cds watch per service, sequentially or in parallel, and the router through cds bind --exec -- npm start.
Conditions: Node.js 22 or newer, which the package states as its requirement a binding the router's own start command can resolve, since it starts the router through cds bind --exec
Remaining work: Configure the services it is to start. The documentation is in German, and the repository declared in the package metadata returns 404, so the npm page is the only thing to read.
Pick up a CDS model change without restarting by hand
A developer edits a CDS file or a handler and the running service answers the next request against the changed model, without stopping and starting it.
Covers the loop between a saved file and a served request. Attaching a debugger to that process is debugging, and what the service is bound to while it runs is a separate outcome.
@sap/cds-dkcds watch watches for changed files and restarts the Node.js server, so the next request is served against the saved model.
Remaining work: Nothing beyond running it. The restart follows any changed file the project holds, seed data included, which is the loop working as documented rather than a setting.
Run a CAP service against a cloud service instance
A service running on a laptop reads and writes through a service instance that exists in the cloud — a database, a destination, an authentication service — instead of through the local substitute, with nothing deployed.
Covers how the local process comes to hold the instance's credentials and what kinds of instance can be reached. The network path to a system behind a firewall is connectivity rather than binding, and the router's login flow is its own outcome.
@sap/cds-dkcds bind records where the credentials can be obtained rather than the credentials themselves, and reaches a managed, a user-provided or a shared Cloud Foundry instance as well as a Kubernetes service binding or a plain secret. The run then starts under that profile: cds watch --profile hybrid on Node.js, and cds bind --exec mvn spring-boot:run for a CAP Java application.
Conditions: the developer is logged in to the target Cloud Foundry space or Kubernetes cluster, which is where cds bind resolves the instance from the same profile name is used to create the binding and to run, since bindings are assigned to the hybrid profile by default
Remaining work: Create the instance and its service key in the cloud and keep the profile name consistent. The binding is resolved when the process starts, so a service only reachable through a tunnel still needs the tunnel.
@sang2x/captoolsbind-local binds the local project to the services of a Cloud Foundry application and writes the resulting VCAP_SERVICES into default-env.json; run-local chains that behind one command with the install step and cds watch --profile hybrid.
Conditions: the target is a Cloud Foundry space with the application already deployed, since the command reads the bound services of an app the resolved VCAP_SERVICES may be written into default-env.json in the project
Remaining work: Keep the written file out of the repository, and read the published dist to know what a command does: there is no repository and no README.
Start a CAP service with nothing bound
A CAP project whose model imports a remote service and whose endpoints are authenticated starts, serves and answers requests on a laptop with no service instance bound, no database provisioned and no upstream system reachable.
Covers what answers in place of the database, the identity provider and the imported service. Reaching a real instance of any of them from the same laptop is hybrid testing and is assessed separately, and what the router in front adds is its own outcome.
@sap/cdsMocks every imported service in process with mock data in the same in-memory database as the project's own data, and authenticates with the pre-defined mock users of its mocked strategy, so a first run needs nothing bound to it.
Remaining work: Supply the mock data as CSV under srv/external/data. An association of a mocked service returns no data until the imported model is extended by hand, and the mocked users say nothing about how the deployed application will authenticate.
@sap/cds-dkcds watch starts the server and the artifacts the in-memory SQLite database needs are created as it runs, with no build step in a Node.js project; cds mock runs the imported service in a separate process where one process is too far from the target setup.
Remaining work: Nothing beyond running it. The database is reset on each application start, so seed data is the only data a fresh run has.
Content
Seen working
Neither the package manifest nor the repository tree declares a licence.
Neither the package manifest nor the repository tree declares a licence.
Details
Coverage
Comparison properties
These are the questions used to compare what the artifacts do. Values come from their documentation and may apply to a particular ecosystem or runtime. Each recorded value in the comparison opens its statement and sources.
For your agent
- Ref
capability:local-development- JSON
- /capabilities/local-development.json
- MCP
- Connecting an agent