Service / orders
http
▲ Address already in use:8080Your application
is a system.Develop it like one.
Portless automatically discovers and runs your services and dependencies — no config required — so you can trace every interaction and reproduce failures, without leaving your local development workflow.
$ portless up
✓ discovered checkout, inventory, orders
✓ started postgres and valkey
✓ store/local healthy · 5/5 ready
http://checkout.local.store.localhost
Run it.See it.Break it.Locally.
The problem
Local development
gets messy fast.
Ports collide. Services scatter across terminals. Dependencies run wherever they happen to fit. Soon the environment is harder to understand than the application.
Service / inventory
http
▲ Address already in use:8080Resource / orders
postgres
▲ Address already in use:5432Resource / inventory
postgres
▲ Address already in use:5432Why Portless
Keep the defaults.
Lose the collisions.
Portless keeps process and container ports private, then publishes service-scoped HTTP and TCP addresses. Orders and inventory can both default to :8080, while both PostgreSQL dependencies remain available on :5432.
orders
localhost:8080conflictinventory
localhost:8080conflictorders-db
localhost:5432conflictinventory-db
localhost:5432conflictorders
orders.local.store.localhostreadyinventory
inventory.local.store.localhostreadyorders-db
orders-db.local.store.portless.testreadyinventory-db
inventory-db.local.store.portless.testreadyRun it
One command starts
the whole application.
Starting work shouldn't mean rebuilding your local environment by hand. Run portless up from any checkout and Portless discovers the application, launches its services and dependencies, and opens the local control plane.
$ portless up- 01Discovers the application around you.
Related checkouts, services, and dependencies are discovered automatically.
- 02Launches in dependency order.
Local processes and managed resources launch in the order they are needed.
- 03Publishes stable service endpoints.
The control plane opens with addresses and health visible for every service.
One application.
Many shapes.
A project can span several repositories. Each environment reuses that topology while deciding what runs from a checkout, in a container, against a remote service, or as a deterministic mock.
- Reuse the same readable service names everywhere
- Mix local, container, remote, and mock providers
- Switch one provider without restarting its callers
Automatic discovery for your stack.
Portless identifies runnable services from the project files already in your checkout. No config required.
More frameworks and resources coming soon
Supported frameworks
Managed resources
See it
Every service.Every interaction.One live view.
Watch real requests cross exact source-to-target edges, with rate and latency attached to the relationships that produced them.
Live system mapTrace every call to its source.
Portless preserves the caller on every dependency edge.
Follow the request. Inspect the exchange.
Trace requests across services, then inspect timing, headers, and captured request and response bodies.
Break it
Beyond the happy path.
Capture a workflow, replace one dependency with a deterministic mock, or inject latency and failures between services. No application code changes required.
Record Traffic
Capture a failing workflow as it happens, then inspect the requests, responses, and timing that led to it.
GET /inventory/coffee-mug
200sold-out{
"available": false,
"reason": "mocked sold out"
}Mock Dependencies
Bind a service to a fixed local response while callers keep the same injected endpoint.
Inject Faults
Target one service connection with latency, error responses, or dropped connections and see how the system reacts.
Locally
Your application. Your machine.
Portless runs locally with no account or hosted service required. Environment state, traffic, recordings, mocks, and faults stay on your machine.
No required project file
Bounded, read-only discovery understands supported application frameworks and managed resources without running project code.
Readable endpoints
Every service gets a stable project and environment-aware address while private runtime ports stay private.
One application, many sources
Model a project across repositories, then choose a local, container, remote, or mock provider for each component.
Local by design
There is no account or hosted control plane. Environment state, traffic, recordings, and faults stay on your machine.
Run it · see it · break it
One system. Ready to debug.
Start the whole application, follow service interactions, and test failures without changing code.
Get started
Up and running.
Install
macOS with Homebrew
brew install runportless/tap/portlessSet up
Once per machine
portless setupRun
From your app's checkout
portless up
Your services start. Your dashboard opens. You're ready.
Run it.See it.Break it.
Locally
Get started