Actyx Reference

Supported OS and architectures

Platform	Supported OS	Supported architecture
Windows	Windows 10 or Windows Server 2019	x86_64
Android	Android 6-10	x86, arm64-v8a or armeabi-v7a ABI
Linux	Ubuntu 18.04+ or Alpine 3.9+	x86_64, aarch64, armv7 or arm
Docker	Docker 20+	x86_64, aarch64, armv7 or arm
macOS	Big Sur	x86_64 or aarch64

Android 11 not supported

Note that Actyx is currently not supported on Android 11. We are on it and will release support for the latest version of Android in one of the coming releases!

Networking Requirements

Device	LAN/WLAN
ports 4001, 4454, 4458 unused Incoming/outgoing connections on ports 4001, 4454, 4458 allowed All nodes connected to same LAN/WLAN	ports 4001, 4454, 4458 unblocked UDP unicast connections allowed (mDNS protocol, port 5353, IPv4 224.0.0.251, IPv6 ff02::fb) Client-isolation disabled

It is not supported to put firewalls between devices of the same swarm. Wherever possible, devices should be placed within one broadcast domain. Placing devices of the same swarm across different broadcast domains requires manually configuring initial peers and configuring communication between these broadcast domains accordingly.

Performance

A lot of different factors play into performance of Actyx and your apps. Assuming a standard network setup, rugged tablets or other devices with relatively low computing power, and a standard factory use case, these are approximate limits:

Type	Performance
Latency	below 200 ms, not guaranteed as dependent on several factors
No. of nodes	max. 100 nodes
Event data rate	~1 event per node per 10 seconds

The following list shows the factors that influence performance. Please note that these are not requirements, but assumptions made for the above performance characteristics:

Factor	Assumption
LAN setup and latency	standard / WiFi
App runtimes	Webview (Node.js) and Docker
Devices	Rugged tablets or other devices with relatively low computing power (e.g. Raspberry Pi 3)
Device CPU	1-2 GHz, x86/arm architecture
Device RAM	1-4 GB
Programming language	Typescript
Business logic complexity	Standard factory use case, production data and machine data acquisition

Assumptions do not fit your use case?

The limits regarding performance and disk space described on this page are only true within the circumstances outlined above. If one of these factors changes, the limits for your solution might change. If you are looking for guidance on a specific use case, please refer to our conceptual guide or contact us.

Disk space requirements

The required disk space depends on the size, number, and compressibility of the events that are emitted by apps built on Actyx. These are example calculations for factory apps, either with or without machine integrations, based on our project experience and for a 1-year time frame:

	With machine integrations	Without machine integrations
Number of nodes	8	10
Number of events	10,000,000	580,000
Disk space needed	65 MB	30 MB

The events used for the above examples contained information on orders and their progress, or machine values (~10) read from a OPC UA interface.

tip

We are already working on the functionality to configure replication and lifespan of events. By configuring when events should be deleted or to which devices they should be replicated, you will be able to optimize for low disk space usage.

Node Settings Schema

Which settings are available and which values they may have is defined in the so-called Actyx Node Setting Schema. The most recent version thereof is available for download at:

https://developer.actyx.com/schemas/node-settings.schema.json

The admin section of the settings holds a list of authorized users, represented by their public keys (you can find yours in your O/S-specific user profile folder under actyx/keys/users/id.pub). If you need to access a node that doesn’t accept your key, but you have administrator access to the (virtual) device it is running on, then you may use ax users add-key to get yourself in — make sure to stop Actyx before doing this. The displayName property is shown in the Node Manager or ax nodes inspect etc., so it is useful to set it to some short string that helps you identify the node. You can change the /admin/logLevels/node setting to adjust the logging output verbosity at runtime; valid values are DEBUG, INFO, WARN, or ERROR.

The /api/events/readOnly setting controls whether the node will send events to the rest of the swarm. Its main use is to create a “silent observer” that you use to test new app versions without risking to taint the swarm with development or test events.

The licensing section is described in licensing apps.

In the swarm section you can fine-tune the networking behavior of Actyx:

• announceAddresses: an array of addresses allows you to declare IP addresses under which the node is reachable, but that are not listen addresses. This is frequently necessary when running Actyx inside a Docker container, see configuring the announceAddresses setting.

• initialPeers: an array of addresses of the form /ip4/<IP address>/tcp/<port>/p2p/<PeerId> to which this node shall immediately try to connect.

• bitswapTimeout: maximal wait time for a data request sent to another swarm node. You may need to increase this on very slow networks if you regularly see bitswap timeout warnings in the logs.

• pingTimeout: Each connection to another Actyx node is continually monitored via messages sent over that TCP connection (they are called “ping”, but have nothing to do with the ping network tool). When three successive pings have not been answered within the allotted timeout, the connection is closed and will be re-established. You may need to increase this on very slow networks if you regularly see ping timeout warnings in the logs.

• blockCacheCount: the number of IPFS data blocks kept in the local actyx-data folder for the current topic. All swarm event data blocks and pinned files will be kept regardless of this setting, only voluntarily cached blocks can be evicted.

• blockCacheSize: the size in bytes up to which data blocks are kept in the local actyx-data folder for the current topic. The same restriction applies as for blocks in that events and pinned files are not eligible for eviction, so the cache may grow larger.

• blockGcInterval: the interval at which eligible data are evicted from the local actyx-data folder for the current topic. There should be no need to change this.

• swarmKey: an additional layer of encryption between Actyx nodes that allows you to separate swarm so that they cannot connect to each other. See the guide on swarm keys.

• topic: a logical separation of nodes within the same swarm — events can only be replicated within the same topic, and each node can only be part of one topic. This is mainly useful for effectively erasing all events within a swarm by switching all nodes to a new topic. The old events will still be in the actyx-data folder, you can access them by switching a node back to the old topic; there will be no interference between old and new topic.