{"id":37206692,"url":"https://github.com/mlctrez/gnatsd","last_synced_at":"2026-01-14T23:47:16.976Z","repository":{"id":57553448,"uuid":"63567689","full_name":"mlctrez/gnatsd","owner":"mlctrez","description":"High-Performance server for NATS, the cloud native messaging system.","archived":false,"fork":true,"pushed_at":"2016-11-26T00:16:01.000Z","size":1380,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-10-10T03:56:33.849Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"https://nats.io","language":"Go","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":"nats-io/nats-server","license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/mlctrez.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2016-07-18T03:34:21.000Z","updated_at":"2016-07-18T03:34:22.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/mlctrez/gnatsd","commit_stats":null,"previous_names":[],"tags_count":14,"template":false,"template_full_name":null,"purl":"pkg:github/mlctrez/gnatsd","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mlctrez%2Fgnatsd","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mlctrez%2Fgnatsd/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mlctrez%2Fgnatsd/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mlctrez%2Fgnatsd/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/mlctrez","download_url":"https://codeload.github.com/mlctrez/gnatsd/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mlctrez%2Fgnatsd/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28439537,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-14T22:37:52.437Z","status":"ssl_error","status_checked_at":"2026-01-14T22:37:31.496Z","response_time":107,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-01-14T23:47:16.338Z","updated_at":"2026-01-14T23:47:16.960Z","avatar_url":"https://github.com/mlctrez.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"##\u003cimg src=\"logos/nats-server.png\" width=\"300\"\u003e\n[![License][License-Image]][License-Url] [![ReportCard][ReportCard-Image]][ReportCard-Url] [![Build][Build-Status-Image]][Build-Status-Url] [![Release][Release-Image]][Release-Url] [![Coverage][Coverage-Image]][Coverage-Url]\n\nA High Performance [NATS](https://nats.io) Server written in [Go.](http://golang.org)\n\n## Quickstart\n\nIf you just want to start using NATS, and you have [installed Go](https://golang.org/doc/install) 1.5+ and set your $GOPATH:\n\nInstall and run the NATS server:\n\n```\ngo get github.com/nats-io/gnatsd\ngnatsd -D -V\n```\n\nInstall the [Go NATS client](https://github.com/nats-io/nats/blob/master/README.md):\n\n```\ngo get github.com/nats-io/go-nats\n```\n\n## Installation\n\nYou can install the NATS server binary or Docker image, connect to a NATS service, or build the server from source.\n\n### Download\n\nThe recommended way to install the NATS server is to [download](http://nats.io/download/) one of the pre-built release binaries which are available for OSX, Linux (x86-64/ARM), Windows, and Docker. Instructions for using these binaries are on the [GitHub releases page][github-release].\n\n### Demo\n\nYou can connect to a public NATS server that is running at our demo site: [nats://demo.nats.io:4222](nats://demo.nats.io:4222), and a secure version at [tls://demo.nats.io:4443](nats://demo.nats.io:4443). See the [protocol](#protocol) section for usage.\n\n### Build\n\nYou can build the latest version of the server from the `master` branch. The master branch generally should build and pass tests, but may not work correctly in your environment. Note that stable branches of operating system packagers provided by your OS vendor may not be sufficient.\n\nYou need [*Go*](http://golang.org/) version 1.5+ [installed](https://golang.org/doc/install) to build the NATS server. We support vendored dependencies, which are fully supported in Go 1.6. For Go 1.5, build with `GO15VENDOREXPERIMENT=1`.\n\n- Run `go version` to verify that you are running Go 1.5+. (Run `go help` for more guidance.)\n- Clone the \u003chttps://github.com/nats-io/gnatsd\u003e repository.\n- Run `go build` inside the `/nats-io/gnatsd` directory. A successful build produces no messages and creates the server executable `gnatsd` in the directory.\n- Run `go test ./...` to run the unit regression tests.\n\n## Running\n\nTo start the NATS server with default settings (and no authentication or clustering), you can invoke the `gnatsd` binary with no [command line options](#command-line-arguments) or [configuration file](#configuration-file).\n\n```sh\n\u003e ./gnatsd\n[37274] 2016/11/20 18:33:12.119961 [INF] Starting nats-server version 0.9.4\n[37274] 2016/11/20 18:33:12.120060 [INF] Listening for client connections on 0.0.0.0:4222\n[37274] 2016/11/20 18:33:12.120154 [INF] Server is ready\n```\n\nThe server is started and listening for client connections on port 4222 (the default) from all available interfaces. The logs are displayed to stdout as shown above in the server output.\n\n### Clients\n\nThe NATS ecosystem provides a large range of supported and community [clients](http://nats.io/documentation/clients/nats-clients/), including Go, Java, Node, and many more. For the complete up-to-date list, visit the [NATS download site](https://nats.io/download).\n\n### Protocol\n\nThe NATS server uses a [text based protocol](http://nats.io/documentation/internals/nats-protocol/), so interacting with it can be as simple as using telnet as shown below. See also the [protocol demo](http://nats.io/documentation/internals/nats-protocol-demo/).\n\n```sh\n\u003e telnet demo.nats.io 4222\nTrying 107.170.221.32...\nConnected to demo.nats.io.\nEscape character is '^]'.\nINFO {\"server_id\":\"kG19DsXX1UVeSyEjhl3RFw\",\"version\":\"0.9.4\",\"go\":\"go1.6.3\",\"host\":\"0.0.0.0\",\"port\":4222, ...}\nSUB foo 1\n+OK\nPUB foo 11\nHello World\n+OK\nMSG foo 1 11\nHello World\n```\n\n## Command line arguments\n\nThe NATS server accepts command line arguments to control its behavior. Usage is shown below. Note that command line arguments override those items in the [configuration file](#configuration-file).\n\n```\nServer Options:\n    -a, --addr HOST                  Bind to HOST address (default: 0.0.0.0)\n    -p, --port PORT                  Use PORT for clients (default: 4222)\n    -P, --pid FILE                   File to store PID\n    -m, --http_port PORT             Use HTTP PORT for monitoring\n    -ms,--https_port PORT            Use HTTPS PORT for monitoring\n    -c, --config FILE                Configuration File\n\nLogging Options:\n    -l, --log FILE                   File to redirect log output\n    -T, --logtime                    Timestamp log entries (default: true)\n    -s, --syslog                     Enable syslog as log method.\n    -r, --remote_syslog              Syslog server addr (udp://localhost:514).\n    -D, --debug                      Enable debugging output\n    -V, --trace                      Trace the raw protocol\n    -DV                              Debug and Trace\n\nAuthorization Options:\n        --user user                  User required for connections\n        --pass password              Password required for connections\n\nTLS Options:\n        --tls                        Enable TLS, do not verify clients (default: false)\n        --tlscert FILE               Server certificate file\n        --tlskey FILE                Private key for server certificate\n        --tlsverify                  Enable TLS, verify client certificates\n        --tlscacert FILE             Client certificate CA for verification\n\nCluster Options:\n        --routes [rurl-1, rurl-2]    Routes to solicit and connect\n        --cluster [cluster url]      Cluster URL for solicited routes\n\nCommon Options:\n    -h, --help                       Show this message\n    -v, --version                    Show version\n        --help_tls                   TLS help\n```\n\n## Configuration file\n\nTypically you configure the NATS server using a configuration file, an example of which is shown below. See also the [server configuration file](http://nats.io/documentation/server/gnatsd-config/) documentation for details on the configuration language.\n\n```\nlisten: localhost:4242 # host/port to listen for client connections\n\nhttp: localhost:8222 # HTTP monitoring port\n\n# Authorization for client connections\nauthorization {\n  user:     derek\n  # ./util/mkpassword -p T0pS3cr3t\n  password: $2a$11$W2zko751KUvVy59mUTWmpOdWjpEm5qhcCZRd05GjI/sSOT.xtiHyG\n  timeout:  1\n}\n\n# Cluster definition\n\ncluster {\n\n  listen: localhost:4244 # host/port for inbound route connections\n\n  # Authorization for route connections\n  authorization {\n    user: route_user\n    # ./util/mkpassword -p T0pS3cr3tT00!\n    password: $2a$11$xH8dkGrty1cBNtZjhPeWJewu/YPbSU.rXJWmS6SFilOBXzmZoMk9m\n    timeout: 0.5\n  }\n\n  # Routes are actively solicited and connected to from this server.\n  # Other servers can connect to us if they supply the correct credentials\n  # in their routes definitions from above.\n\n  routes = [\n    nats-route://user1:pass1@127.0.0.1:4245\n    nats-route://user2:pass2@127.0.0.1:4246\n  ]\n}\n\n# logging options\ndebug:   false\ntrace:   true\nlogtime: false\nlog_file: \"/tmp/nats-server.log\"\n\n# pid file\npid_file: \"/tmp/nats-server.pid\"\n\n# Some system overides\n\n# max_connections\nmax_connections: 100\n\n# maximum protocol control line\nmax_control_line: 512\n\n# maximum payload\nmax_payload: 65536\n\n# slow consumer threshold\nmax_pending_size: 10000000\n```\n\n## Variables\n\nThe NATS sever configuration language supports block-scoped variables that can be used for templating in the configuration file, and specifically to ease setting of group values for [permission fields](#authorization) and [user authentication](#authentication).\n\nVariables can be referenced by the prefix `$`, for example: `$PASSWORD`. Variables can be defined in the configuration file itself or reference environment variables.\n\nAny value in the configuration language can be a variable reference (`key=$VALUE`). Note that the variable identifier (name) is not case sensitive, but is capitalized by convention for readability.\n\n## Clustering\n\nClustering lets you scale NATS messaging by having multiple NATS servers communicate with each other. Clustering lets messages published to one server be routed and received by a subscriber on another server. See also the [clustered NATS](http://nats.io/documentation/server/gnatsd-cluster/) documentation.\n\n### Full mesh required\n\nIn order for clustering to work correctly, all NATS servers must be connected to each other.\n\nNATS servers have a forwarding limit of one hop. This means that each server will **only** forward a message that it has received **from a client** to  all connected servers that expressed interest in the message's published subject. A message received **from** a route will only be distributed to local clients.\n\n### Configuration options\n\nNATS supports running each server in clustered mode. The following command line options are supported:\n\n    --cluster [cluster url]     Cluster URL for solicited routes\n    --routes [rurl-1, rurl-2]   Routes to solicit and connect\n\nThe `--cluster` flag specifies the NATS URL where the server listens for connections from other servers.\n\nThe `--routes` flag specifies the NATS URL for one or more servers in the cluster. When a server connects to a specified route, it will advertise its own cluster URL to other servers. Note that when the `--routes` option is specified a `--cluster` option is also required.\n\nPrevious releases required you to build the complete mesh using the `--routes` flag. To define your cluster in the current release, please follow the \"Basic example\" as described below.\n\n### Basic example\n\nNATS makes building the full mesh easy. Simply designate a server to be a *seed* server. All other servers in the cluster simply specify the *seed* server as its server's routes option as indicated below.\n\nWhen running NATS Servers in different hosts, the command line parameters for all servers could be as simple as:\n\n```\ngnatsd --cluster nats://$HOSTNAME:$NATS_CLUSTER_PORT --routes nats://$NATS_SEED_HOST:$NATS_CLUSTER_PORT\n```\n\nEven on the host where the *seed* is running, the above would work as the server would detect an attempt to connect to itself and ignore that. In other words, the same command line could be deployed in several hosts and the full mesh will properly form.\n\nNote that you don't have to connect all servers to the same *seed* server, any server accepting a connection will inform other servers in the mesh about that new server so that they can connect to it. The advantage of the seed approach, is that you can deploy the same configuration to all hosts.\n\n### 3-node example\n\nThe following example demonstrates how to run a cluster of 3 servers on the same host. We will start with the seed server and use the `-D` command line parameter to produce debug information.\n\nSee also [clustered NATS](http://nats.io/documentation/server/gnatsd-cluster/) for clustered NATS examples using Docker.\n\n```\ngnatsd -p 4222 -cluster nats://localhost:4248 -D\n```\n\nAlternatively, you could use a configuration file, let's call it `seed.conf`, with a content similar to this:\n\n```\n# Cluster Seed Node\n\nlisten: 127.0.0.1:4222\nhttp: 8222\n\ncluster {\n  listen: 127.0.0.1:4248\n}\n```\n\nAnd start the server like this:\n\n```\ngnatsd -config ./seed.conf -D\n```\n\nThis will produce an output similar to:\n\n```\n[75653] 2016/04/26 15:14:47.339321 [INF] Listening for route connections on 127.0.0.1:4248\n[75653] 2016/04/26 15:14:47.340787 [INF] Listening for client connections on 127.0.0.1:4222\n[75653] 2016/04/26 15:14:47.340822 [DBG] server id is xZfu3u7usAPWkuThomoGzM\n[75653] 2016/04/26 15:14:47.340825 [INF] server is ready\n```\n\nIt is also possible to specify the hostname and port independently. At least the port is required. If you leave the hostname off it will bind to all the interfaces ('0.0.0.0').\n\n```\ncluster {\n  host: 127.0.0.1\n  port: 4248\n}\n```\n\nNow let's start two more servers, each one connecting to the seed server.\n\n```\ngnatsd -p 5222 -cluster nats://localhost:5248 -routes nats://localhost:4248 -D\n```\n\nWhen running on the same host, we need to pick different ports for the client connections `-p`, and for the port used to accept other routes `-cluster`. Note that `-routes` points to the `-cluster` address of the seed server (`localhost:4248`).\n\nHere is the log produced. See how it connects and registers a route to the seed server (`...GzM`).\n\n```\n[75665] 2016/04/26 15:14:59.970014 [INF] Listening for route connections on localhost:5248\n[75665] 2016/04/26 15:14:59.971150 [INF] Listening for client connections on 0.0.0.0:5222\n[75665] 2016/04/26 15:14:59.971176 [DBG] server id is 53Yi78q96t52QdyyWLKIyE\n[75665] 2016/04/26 15:14:59.971179 [INF] server is ready\n[75665] 2016/04/26 15:14:59.971199 [DBG] Trying to connect to route on localhost:4248\n[75665] 2016/04/26 15:14:59.971551 [DBG] 127.0.0.1:4248 - rid:1 - Route connection created\n[75665] 2016/04/26 15:14:59.971559 [DBG] 127.0.0.1:4248 - rid:1 - Route connect msg sent\n[75665] 2016/04/26 15:14:59.971720 [DBG] 127.0.0.1:4248 - rid:1 - Registering remote route \"xZfu3u7usAPWkuThomoGzM\"\n[75665] 2016/04/26 15:14:59.971731 [DBG] 127.0.0.1:4248 - rid:1 - Route sent local subscriptions\n```\n\nFrom the seed's server log, we see that the route is indeed accepted:\n\n```\n[75653] 2016/04/26 15:14:59.971602 [DBG] 127.0.0.1:52679 - rid:1 - Route connection created\n[75653] 2016/04/26 15:14:59.971733 [DBG] 127.0.0.1:52679 - rid:1 - Registering remote route \"53Yi78q96t52QdyyWLKIyE\"\n[75653] 2016/04/26 15:14:59.971739 [DBG] 127.0.0.1:52679 - rid:1 - Route sent local subscriptions\n```\n\nFinally, let's start the third server:\n\n```\ngnatsd -p 6222 -cluster nats://localhost:6248 -routes nats://localhost:4248 -D\n```\n\nAgain, notice that we use a different client port and cluster address, but still point to the same seed server at the address `nats://localhost:4248`:\n\n```\n[75764] 2016/04/26 15:19:11.528185 [INF] Listening for route connections on localhost:6248\n[75764] 2016/04/26 15:19:11.529787 [INF] Listening for client connections on 0.0.0.0:6222\n[75764] 2016/04/26 15:19:11.529829 [DBG] server id is IRepas80TBwJByULX1ulAp\n[75764] 2016/04/26 15:19:11.529842 [INF] server is ready\n[75764] 2016/04/26 15:19:11.529872 [DBG] Trying to connect to route on localhost:4248\n[75764] 2016/04/26 15:19:11.530272 [DBG] 127.0.0.1:4248 - rid:1 - Route connection created\n[75764] 2016/04/26 15:19:11.530281 [DBG] 127.0.0.1:4248 - rid:1 - Route connect msg sent\n[75764] 2016/04/26 15:19:11.530408 [DBG] 127.0.0.1:4248 - rid:1 - Registering remote route \"xZfu3u7usAPWkuThomoGzM\"\n[75764] 2016/04/26 15:19:11.530414 [DBG] 127.0.0.1:4248 - rid:1 - Route sent local subscriptions\n[75764] 2016/04/26 15:19:11.530595 [DBG] 127.0.0.1:52727 - rid:2 - Route connection created\n[75764] 2016/04/26 15:19:11.530659 [DBG] 127.0.0.1:52727 - rid:2 - Registering remote route \"53Yi78q96t52QdyyWLKIyE\"\n[75764] 2016/04/26 15:19:11.530664 [DBG] 127.0.0.1:52727 - rid:2 - Route sent local subscriptions\n```\n\nFirst a route is created to the seed server (`...GzM`) and after that, a route from `...IyE` - which is the ID of the second server - is accepted.\n\nThe log from the seed server shows that it accepted the route from the third server:\n\n```\n[75653] 2016/04/26 15:19:11.530308 [DBG] 127.0.0.1:52726 - rid:2 - Route connection created\n[75653] 2016/04/26 15:19:11.530384 [DBG] 127.0.0.1:52726 - rid:2 - Registering remote route \"IRepas80TBwJByULX1ulAp\"\n[75653] 2016/04/26 15:19:11.530389 [DBG] 127.0.0.1:52726 - rid:2 - Route sent local subscriptions\n```\n\nAnd the log from the second server shows that it connected to the third.\n\n```\n[75665] 2016/04/26 15:19:11.530469 [DBG] Trying to connect to route on 127.0.0.1:6248\n[75665] 2016/04/26 15:19:11.530565 [DBG] 127.0.0.1:6248 - rid:2 - Route connection created\n[75665] 2016/04/26 15:19:11.530570 [DBG] 127.0.0.1:6248 - rid:2 - Route connect msg sent\n[75665] 2016/04/26 15:19:11.530644 [DBG] 127.0.0.1:6248 - rid:2 - Registering remote route \"IRepas80TBwJByULX1ulAp\"\n[75665] 2016/04/26 15:19:11.530650 [DBG] 127.0.0.1:6248 - rid:2 - Route sent local subscriptions\n```\n\nAt this point, there is a full mesh cluster of NATS servers.\n\n## Securing NATS\n\nThis section describes how to secure the NATS server, including authentication, authorization, and encryption using TLS and bcrypt.\n\n### Authentication\n\nThe NATS server supports single and multi-user/client authentication. See also the [server authentication](http://nats.io/documentation/server/gnatsd-authentication/) documentation.\n\n**Single user authentication**\n\nFor single-user authentication, you can start the NATS server with authentication enabled by passing in the required credentials on the command line, or by passing in a token.\n\n```\ngnatsd -DV --user foo --pass bar\n```\n\n```\ngnatsd -DV -auth 'S3Cr3T0k3n!'\n```\n\nClients can connect using:\n\n```\nnats://foo:bar@localhost:4222\n```\n\n```\nnats://S3Cr3T0k3n!@localhost:4222\n```\n\nYou can also enable single-user authentication and set the credentials in the server configuration file as follows:\n\n```\nauthorization {\n  user:     derek\n  password: T0pS3cr3t\n  timeout:  1\n}\n```\n\n**Multi-user authentication**\n\nYou can enable multi-user authentication using a NATS server configuration file that defines user credentials (`user` and `password`), and optionally `permissions`, for two or more users. Multi-user authentication leverages [variables](#variables).\n\n```\nauthorization {\n  users = [\n    {user: value or $VARIABLE, password: value or $VARIABLE}\n    {user: value or $VARIABLE, password: value or $VARIABLE, [permissions: $PERMISSION]}\n    ...\n  ]\n}\n```\n\nFor example:\n\n```\nauthorization {\n  PASS: abcdefghijklmnopqrstuvwxwz0123456789\n  users = [\n    {user: alice, password: foo, permissions: $ADMIN}\n    {user: bob,   password: bar, permissions: $REQUESTOR}\n    {user: joe,   password: $PASS}\n  ]\n}\n```\n\n### Authorization\n\nThe NATS server supports authorization using subject-level permissions on a per-user basis. Permission-based authorization is available with [multi-user authentication](#authentication). See also the [Server Authorization](http://nats.io/documentation/server/gnatsd-authorization) documentation.\n\nEach permission grant is an object with two fields: what subject(s) the authenticated user can publish to, and what subject(s) the authenticated user can subscribe to. The parser is generous at understanding what the intent is, so both arrays and singletons are processed. Subjects themselves can contain wildcards. Permissions make use of [variables](#variables).\n\nYou set permissions by creating an entry inside of the `authorization` configuration block that conforms to the following syntax:\n\n```\nauthorization {\n  PERMISSION_NAME = {\n    publish = \"singleton\" or [\"array\", ...]\n    subscribe = \"singleton\" or [\"array\", ...]\n  }\n}\n```\n\nHere is an example authorization configuration that defines three users, two of whom are assigned explicit permissions.\n\n```\nauthorization {\n  ADMIN = {\n    publish = \"\u003e\"\n    subscribe = \"\u003e\"\n  }\n  REQUESTOR = {\n    publish = [\"req.foo\", \"req.bar\"]\n    subscribe = \"_INBOX.*\"\n  }\n  DEFAULT_PERMISSIONS = {\n    publish = \"SANDBOX.*\"\n    subscribe = [\"PUBLIC.\u003e\", \"_INBOX.\u003e\"]\n  }\n\n  PASS: abcdefghijklmnopqrstuvwxwz0123456789\n  users = [\n    {user: alice, password: foo, permissions: $ADMIN}\n    {user: bob,   password: bar, permissions: $REQUESTOR}\n    {user: joe,   password: $PASS}\n  ]\n}\n```\n\nSince Alice is an ADMIN she can publish/subscribe on any subject. We use the wildcard “\u003e” to match any subject.\n\nBob is REQUESTOR and can publish requests on subjects \"req.foo\" or \"req.bar\", and subscribe to anything that is a response (\"_INBOX.*\").\n\nJoe has no permission grant and therefore inherits the default permission set. You set the inherited default permissions by assigning them to the `default_permissions` entry inside of the `authorization` configuration block.\n\nNote that `_INBOX.*` subscribe permissions must be granted in order to use the request APIs in Apcera supported clients. If an unauthorized client publishes or attempts to subscribe to a subject, the action fails and is logged at the server, and an error message is returned to the client.\n\n### TLS\n\nAs of Release 0.7.0, the server can use modern TLS semantics for client connections, route connections, and the HTTPS monitoring port.\nThe server requires TLS version 1.2, and sets preferences for modern cipher suites that avoid those known with vunerabilities. The\nserver's preferences when building with Go1.5 are as follows.\n\n```go\nfunc defaultCipherSuites() []uint16 {\n\treturn []uint16{\n\t\t// The SHA384 versions are only in Go1.5+\n\t\ttls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,\n\t\ttls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,\n\t\ttls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,\n\t\ttls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,\n\t}\n}\n```\n\nGenerating self signed certs and intermediary certificate authorities is beyond the scope here, but this document can be helpful in addition to Google Search: \u003ca href=\"https://docs.docker.com/engine/articles/https/\" target=\"_blank\"\u003ehttps://docs.docker.com/engine/articles/https/\u003c/a\u003e.\n\nThe server **requires** a certificate and private key. Optionally the server can require that clients need to present certificates, and the server can be configured with a CA authority to verify the client certificates.\n\n```\n# Simple TLS config file\n\nlisten: 127.0.0.1:4443\n\ntls {\n  cert_file:  \"./configs/certs/server-cert.pem\"\n  key_file:   \"./configs/certs/server-key.pem\"\n  timeout:    2\n}\n\nauthorization {\n  user:     derek\n  password: $2a$11$W2zko751KUvVy59mUTWmpOdWjpEm5qhcCZRd05GjI/sSOT.xtiHyG\n  timeout:  1\n}\n```\n\nIf requiring client certificates as well, simply change the TLS section as follows.\n\n```\ntls {\n  cert_file: \"./configs/certs/server-cert.pem\"\n  key_file:  \"./configs/certs/server-key.pem\"\n  ca_file:   \"./configs/certs/ca.pem\"\n  verify:    true\n}\n```\n\nWhen setting up clusters, all servers in the cluster, if using TLS, will both verify the connecting endpoints and the server responses. So certificates are checked in both directions. Certificates can be configured only for the server's cluster identity, keeping client and server certificates separate from cluster formation.\n\n```\ncluster {\n  listen: 127.0.0.1:4244\n\n  tls {\n    # Route cert\n    cert_file: \"./configs/certs/srva-cert.pem\"\n    # Private key\n    key_file:  \"./configs/certs/srva-key.pem\"\n    # Optional certificate authority verifying connected routes\n    # Required when we have self-signed CA, etc.\n    ca_file:   \"./configs/certs/ca.pem\"\n  }\n  # Routes are actively solicited and connected to from this server.\n  # Other servers can connect to us if they supply the correct credentials\n  # in their routes definitions from above.\n  routes = [\n    nats-route://127.0.0.1:4246\n  ]\n}\n```\n\nThe server can be run using command line arguments to enable TLS functionality.\n\n```\n--tls                        Enable TLS, do not verify clients (default: false)\n--tlscert FILE               Server certificate file\n--tlskey FILE                Private key for server certificate\n--tlsverify                  Enable TLS, verify client certificates\n--tlscacert FILE             Client certificate CA for verification\n```\n\nExamples using the test certificates which are self signed for localhost and 127.0.0.1.\n\n```bash\n\u003e ./gnatsd --tls --tlscert=./test/configs/certs/server-cert.pem --tlskey=./test/configs/certs/server-key.pem\n\n[2935] 2016/04/26 13:34:30.685413 [INF] Starting nats-server version 0.8.0.beta\n[2935] 2016/04/26 13:34:30.685509 [INF] Listening for client connections on 0.0.0.0:4222\n[2935] 2016/04/26 13:34:30.685656 [INF] TLS required for client connections\n[2935] 2016/04/26 13:34:30.685660 [INF] Server is ready\n```\n\nNotice that the log  indicates that the client connections will be required to use TLS. If you run the server in Debug mode with -D or -DV, the logs will show the cipher suite selection for each connected client.\n\n```\n[15146] 2015/12/03 12:38:37.733139 [DBG] ::1:63330 - cid:1 - Starting TLS client connection handshake\n[15146] 2015/12/03 12:38:37.751948 [DBG] ::1:63330 - cid:1 - TLS handshake complete\n[15146] 2015/12/03 12:38:37.751959 [DBG] ::1:63330 - cid:1 - TLS version 1.2, cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256\n```\n\nIf you want the server to enforce and require client certificates as well via the command line, utilize this example.\n\n```\n\u003e ./gnatsd --tlsverify --tlscert=./test/configs/certs/server-cert.pem --tlskey=./test/configs/certs/server-key.pem --tlscacert=./test/configs/certs/ca.pem\n```\n\n### Bcrypt\n\nIn addition to TLS functionality, the server now also supports bcrypt for passwords and tokens. This is transparent and you can simply replace the plaintext password in the configuration with the bcrypt hash, the server will automatically utilize bcrypt as needed.\n\nThere is a utility bundled under /util/mkpasswd. By default with no arguments it will generate a secure password and the associated hash. This can be used for a password or a token in the configuration. If you already have a password selected, you can supply that on stdin with the -p flag.\n\n```bash\n~/go/src/github.com/nats-io/gnatsd/util\u003e ./mkpasswd\npass: #IclkRPHUpsTmACWzmIGXr\nbcrypt hash: $2a$11$3kIDaCxw.Glsl1.u5nKa6eUnNDLV5HV9tIuUp7EHhMt6Nm9myW1aS\n```\n\nAdd into the server configuration file's authorization section.\n```\n  authorization {\n    user: derek\n    password: $2a$11$3kIDaCxw.Glsl1.u5nKa6eUnNDLV5HV9tIuUp7EHhMt6Nm9myW1aS\n  }\n```\n\n## Monitoring\n\nIf the monitoring port is enabled, the NATS server runs a lightweight HTTP server that has the following endpoints: /varz, /connz, /routez, and /subsz. All endpoints return a JSON object. See [NATS Server monitoring](http://nats.io/documentation/server/gnatsd-monitoring/) for endpoint examples.\n\nTo see a demonstration of NATS monitoring, run a command similar to the following for each desired endpoint:\n\n```\ncurl demo.nats.io:8222/varz\n```\n\nTo enable the monitoring server, start the NATS server with the monitoring flag `-m` (or `-ms`) and specify the monitoring port.\n\nMonitoring options\n\n    -m, --http_port PORT             HTTP PORT for monitoring\n    -ms,--https_port PORT            Use HTTPS PORT for monitoring (requires TLS cert and key)\n\nTo enable monitoring via the configuration file, use `host:port` (there is no explicit configuration flag for the monitoring interface).\n\nFor example, running the `gnatsd -m 8222` command, you should see that the NATS server starts with the HTTP monitoring port enabled. To view the monitoring home page, go to \u003ca href=\"http://localhost:8222/\" target=\"_blank\"\u003ehttp://localhost:8222/\u003c/a\u003e.\n\n```\n[83249] 2016/06/23 19:39:35.173557 [INF] Starting nats-server version 0.8.0\n[83249] 2016/06/23 19:39:35.173835 [INF] Starting http monitor on 0.0.0.0:8222\n[83249] 2016/06/23 19:39:35.175193 [INF] Listening for client connections on 0.0.0.0:4222\n[83249] 2016/06/23 19:39:35.175226 [INF] Server is ready\n```\n\n## License\n\n(The MIT License)\n\nCopyright (c) 2012-2016 Apcera Inc.\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to\ndeal in the Software without restriction, including without limitation the\nrights to use, copy, modify, merge, publish, distribute, sublicense, and/or\nsell copies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in\nall copies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\nFROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\nIN THE SOFTWARE.\n\n[License-Url]: http://opensource.org/licenses/MIT\n[License-Image]: https://img.shields.io/npm/l/express.svg\n[Build-Status-Url]: http://travis-ci.org/nats-io/gnatsd\n[Build-Status-Image]: https://travis-ci.org/nats-io/gnatsd.svg?branch=master\n[Release-Url]: https://github.com/nats-io/gnatsd/releases/tag/v0.9.4\n[Release-image]: http://img.shields.io/badge/release-v0.9.4-1eb0fc.svg\n[Coverage-Url]: https://coveralls.io/r/nats-io/gnatsd?branch=master\n[Coverage-image]: https://coveralls.io/repos/github/nats-io/gnatsd/badge.svg?branch=master\n[ReportCard-Url]: http://goreportcard.com/report/nats-io/gnatsd\n[ReportCard-Image]: http://goreportcard.com/badge/github.com/nats-io/gnatsd\n[github-release]: https://github.com/nats-io/gnatsd/releases/\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmlctrez%2Fgnatsd","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmlctrez%2Fgnatsd","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmlctrez%2Fgnatsd/lists"}