A workspace is the project boundary
A workspace holds data connections, published layers and coverages, styles, credentials, and OGC service settings. Use separate workspaces when projects need distinct catalogs, metadata, or access policies. Workspace isolation does not create a separate operating-system process for each project.
Workspace URLs accept a workspace name or UUID. For a workspace named tutorial-ui, the feature API starts at /workspaces/tutorial-ui/ogc and the map service at /workspaces/tutorial-ui/wms.
Stores connect to sources
The console calls a data connection a store. The management API calls the same resource a service. For example, the Stores page manages resources under /api/v1/workspaces/{workspace}/services.
Connecting a store does not publish all of its data. Test the connection, discover the available layers or coverages, and explicitly publish the datasets you need. The data-source reference describes supported types, formats, paths, and capabilities.
Publications expose selected data
- A layer exposes a vector dataset such as a PostGIS geometry table, GeoParquet file, or supported vector-file layer.
- A coverage exposes raster data through WCS and compatible map rendering.
- A layer group orders multiple publications for a composed map.
- A style controls server-rendered portrayal. The diagnostic GeoJSON preview uses its own colors and is not proof that a WMS style is correct.
Choose stable public identifiers because clients use them in requests. Unpublishing a layer and deleting its underlying source data are different actions.
Protocols and access are separate
Three settings must agree before a client can use a publication: the source and publication must be enabled, the requested protocol must be available, and the caller must have access. A successful administrator preview does not make a layer public.
OGC API Features is enabled for new workspaces by default. Optional services are controlled globally and per workspace. See workspace settings and authentication before exposing endpoints.
What neoserver stores
The encrypted DuckDB catalog holds configuration and security state. Feature data normally stays in the connected source systems. Managed uploads, cache payloads, audit history, mosaic state, and other enabled subsystems have their own persistence requirements.
Preserve the catalog encryption key and the complete set of state needed by your deployment. The catalog has a single active writer. Follow the deployment guide for initialization, backups, and upgrades.
Choose an interface
The browser console and automation scripts use the same management API. GIS clients use the published OGC endpoints. The console needs an administrator role; application readers should use a narrowly scoped viewer key.
Continue with the console tutorial or the API tutorial.