NYSSR.NET / RESOURCES

A self-hosted runtime for unusual service topologies

Explore a self-hosted Java runtime for applications that need many small services, flexible placement, and integrated communication across connected nodes.

Some applications do not fit a simple one-service-per-container topology: services may need to stay near local systems, share a runtime, or move between nodes without changing their callers. nyssr.net is designed for those cases.

nyssr.net is a network of interconnected Java nodes. Messages flow between them through TCP channels — no central server, no manual routing, and no single point of failure.

A small network of nodes with moon/planet names as ID

A small network of nodes with moon/planet names as ID.

A node, not a container

Every node runs a micro-kernel that loads features as plugins at startup. Even TCP and the transport layer are plugins — anything that is not hardcoded can be swapped or replaced.

A single node can host hundreds of plugins. To deploy a new microservice, add it to the plugin list. To remove one, take it out.

A small network of nodes with plugins

A node can host services, applications, and transport features as plugins.

Objects, not addresses

Any code can send a message, but only registered objects, called targets, can receive one. Each target gets a unique address across the network.

Applications do not need to manage those addresses directly. A transport layer registers microservices under simple IDs such as database statistics. Send a message to that ID and the system routes it to a working instance, wherever it runs.

Sending a message with automatic microservice resolution and response

Messages are routed by ID, not by address.

When multiple instances use the same ID, the registry selects one — load balancing is built in. No extra service mesh or configuration is required.

Key idea: Adding a microservice takes one function call or one message. It can be usable within minutes.

Designed for many small services

nyssr.net is designed to host hundreds of small services without configuration overhead. Services can be written, deployed, and maintained independently.

  • Independent APIs let clients and services evolve at different speeds
  • A service can run on any node — clients do not need to know where
  • Redundancy provides scaling and fault tolerance
  • No topics or queues need to be configured
  • Messages can be delivered to one or more targets across the network
  • Responses are available by default unless explicitly disabled

Operations: Add nodes for capacity, use plugin lists for configuration, and route around failed nodes.