Publish only the public edge
Private services do not receive a public HTTP route. Your public web app can call the internal service over the environment’s private network.
Private services
A place for the parts
behind your product.
Run internal APIs and supporting services on Openstead’s private network. Connect them to other services in the same environment without publishing a public address.
Your code. Infrastructure included.
The public web
YOUR PROJECT · SAME REGION
Your applicationPublic web service
PostgreSQLPrivate connection
Internal APINo public endpoint
Private connections between the services in your project.
Internal addressService discovery by hostname
Same environmentPrivate service connectivity
No public routeExpose only your public application
PRIVATE SERVICES ON OPENSTEAD
Keep internal work behind the public application.
Separate the components of your stack without putting every service on the internet. Each private service has its own build, configuration and resources.
Deploy components independently
Use a separate repository or a directory within a monorepo. Configure a start command and port for the service, then deploy changes on its own lifecycle.
Connect with a hostname
Use the internal service address from the console in your application configuration. Keep service credentials in environment variables.
MADE FOR YOUR STACK
The normal network client. An internal destination.
A private service listens on its configured port just like a web application. Other services in the same environment use its internal hostname to reach it.
- No custom domain is needed for internal service calls.
- Each service has an independent application resource plan.
- Application authentication remains under your control.
Connecting an internal APIopenstead / configuration
EXAMPLE CONFIGURATION# Public web application environment
CATALOG_API_URL=http://catalog:8080
CATALOG_API_TOKEN=your-service-token
# Private catalog service
HOST=0.0.0.0
PORT=8080
# Both services share an environment.Use the actual internal hostname shown in the console. Authenticate calls to sensitive application endpoints.
PUT IT TO WORK
Built for the work
your application does.
Internal APIs
Keep supporting HTTP endpoints behind the application that authenticates and serves your customers.
Processing services
Run an internal document processor or other component your web application calls over the network.
Application components
Split a larger application into services with independent commands, dependencies and release cycles.
HOW IT WORKS
Deploy privately. Connect explicitly.
Create an internal service
Choose Private Service, select your source and configure the application’s command and listening port.
Place callers in the same environment
Keep the services that need to communicate together. Copy the private hostname into the caller’s configuration.
Test the application connection
Verify calls from the web app or worker, check logs and retain application authentication for sensitive endpoints.
Can visitors access a private service directly?
Private services do not receive a public web route. A public web service can call them through the private network when both services are in the same environment.
Do I need a separate repository?
No. You can use a separate repository or choose a directory and command within the same repository as another application component.
Can a private service connect to my database?
Yes. Use the private database hostname and credentials, and place the services in the same environment.
Should my internal API still authenticate requests?
Yes. Use application authentication and authorization for sensitive operations. Private connectivity controls how a service is reached; your application decides which requests it accepts.
MAKE YOUR NEXT MOVE
Build the parts that power the whole.
Your code. Infrastructure included.