ArangoDB v2.8 reached End of Life (EOL) and is no longer supported.

This documentation is outdated. Please see the most recent version here: Try latest

Command-Line Options for arangod

Endpoint

--server.endpoint endpoint
Specifies an endpoint for HTTP requests by clients. Endpoints have the following pattern:

  • tcp://ipv4-address:port - TCP/IP endpoint, using IPv4
  • tcp://[ipv6-address]:port - TCP/IP endpoint, using IPv6
  • ssl://ipv4-address:port - TCP/IP endpoint, using IPv4, SSL encryption
  • ssl://[ipv6-address]:port - TCP/IP endpoint, using IPv6, SSL encryption
  • unix:///path/to/socket - Unix domain socket endpoint
    If a TCP/IP endpoint is specified without a port number, then the default port (8529) will be used. If multiple endpoints need to be used, the option can be repeated multiple times.

Examples 

unix> ./arangod --server.endpoint tcp://127.0.0.1:8529
  --server.endpoint ssl://127.0.0.1:8530
  --server.keyfile server.pem /tmp/vocbase
2012-07-26T07:07:47Z [8161] INFO using SSL protocol version 'TLSv1'
2012-07-26T07:07:48Z [8161] INFO using endpoint 'ssl://127.0.0.1:8530' for http ssl requests
2012-07-26T07:07:48Z [8161] INFO using endpoint 'tcp://127.0.0.1:8529' for http tcp requests
2012-07-26T07:07:49Z [8161] INFO ArangoDB (version 1.1.alpha) is ready for business
2012-07-26T07:07:49Z [8161] INFO Have Fun!


Note: If you are using SSL-encrypted endpoints, you must also supply the path to a server certificate using the --server.keyfile option.
Endpoints can also be changed at runtime. Please refer to HTTP Interface for Endpoints for more details.

Reuse address

--server.reuse-address
If this boolean option is set to true then the socket option SO_REUSEADDR is set on all server endpoints, which is the default. If this option is set to false it is possible that it takes up to a minute after a server has terminated until it is possible for a new server to use the same endpoint again. This is why this is activated by default.
Please note however that under some operating systems this can be a security risk because it might be possible for another process to bind to the same address and port, possibly hijacking network traffic. Under Windows, ArangoDB additionally sets the flag SO_EXCLUSIVEADDRUSE as a measure to alleviate this problem.

Disable authentication

--server.disable-authentication
Setting value to true will turn off authentication on the server side so all clients can execute any action without authorization and privilege checks.
The default value is false.

Disable authentication-unix-sockets

--server.disable-authentication-unix-sockets value
Setting value to true will turn off authentication on the server side for requests coming in via UNIX domain sockets. With this flag enabled, clients located on the same host as the ArangoDB server can use UNIX domain sockets to connect to the server without authentication. Requests coming in by other means (e.g. TCP/IP) are not affected by this option.
The default value is false.
Note: this option is only available on platforms that support UNIX domain sockets.

Authenticate system only

--server.authenticate-system-only boolean
Controls whether incoming requests need authentication only if they are directed to the ArangoDB’s internal APIs and features, located at /_api/, /_admin/ etc.
IF the flag is set to true, then HTTP authentication is only required for requests going to URLs starting with /_, but not for other URLs. The flag can thus be used to expose a user-made API without HTTP authentication to the outside world, but to prevent the outside world from using the ArangoDB API and the admin interface without authentication. Note that checking the URL is performed after any database name prefix has been removed. That means when the actual URL called is /_db/_system/myapp/myaction, the URL /myapp/myaction will be used for authenticate-system-only check.
The default is false.
Note that authentication still needs to be enabled for the server regularly in order for HTTP authentication to be forced for the ArangoDB API and the web interface. Setting only this flag is not enough.
You can control ArangoDB’s general authentication feature with the --server.disable-authentication flag.

Disable replication-applier

--server.disable-replication-applier flag
If true the server will start with the replication applier turned off, even if the replication applier is configured with the autoStart option. Using the command-line option will not change the value of the autoStart option in the applier configuration, but will suppress auto-starting the replication applier just once.
If the option is not used, ArangoDB will read the applier configuration from the file REPLICATION-APPLIER-CONFIG on startup, and use the value of the autoStart attribute from this file.
The default is false.

Keep-alive timeout

--server.keep-alive-timeout
Allows to specify the timeout for HTTP keep-alive connections. The timeout value must be specified in seconds. Idle keep-alive connections will be closed by the server automatically when the timeout is reached. A keep-alive-timeout value 0 will disable the keep alive feature entirely.

Default API compatibility

--server.default-api-compatibility
This option can be used to determine the API compatibility of the ArangoDB server. It expects an ArangoDB version number as an integer, calculated as follows:
10000 * major + 100 * minor (example: *10400 for ArangoDB 1.4)*
The value of this option will have an influence on some API return values when the HTTP client used does not send any compatibility information.
In most cases it will be sufficient to not set this option explicitly but to keep the default value. However, in case an “old” ArangoDB client is used that does not send any compatibility information and that cannot handle the responses of the current version of ArangoDB, it might be reasonable to set the option to an old version number to improve compatibility with older clients.

Hide Product header

--server.hide-product-header
If true, the server will exclude the HTTP header “Server: ArangoDB” in HTTP responses. If set to false, the server will send the header in responses.
The default is false.

Allow method override

--server.allow-method-override
When this option is set to true, the HTTP request method will optionally be fetched from one of the following HTTP request headers if present in the request:

  • x-http-method
  • x-http-method-override
  • x-method-override
    If the option is set to true and any of these headers is set, the request method will be overridden by the value of the header. For example, this allows issuing an HTTP DELETE request which to the outside world will look like an HTTP GET request. This allows bypassing proxies and tools that will only let certain request types pass.
    Setting this option to true may impose a security risk so it should only be used in controlled environments.
    The default value for this option is false.

Server threads

--server.threads number
Specifies the number of threads that are spawned to handle HTTP REST requests.

Keyfile

--server.keyfile filename
If SSL encryption is used, this option must be used to specify the filename of the server private key. The file must be PEM formatted and contain both the certificate and the server’s private key.
The file specified by filename should have the following structure: 

# create private key in file "server.key"
openssl genrsa -des3 -out server.key 1024
<br />
# create certificate signing request (csr) in file "server.csr"
openssl req -new -key server.key -out server.csr
<br />
# copy away original private key to "server.key.org"
cp server.key server.key.org
<br />
# remove passphrase from the private key
openssl rsa -in server.key.org -out server.key
<br />
# sign the csr with the key, creates certificate PEM file "server.crt"
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
<br />
# combine certificate and key into single PEM file "server.pem"
cat server.crt server.key > server.pem


You may use certificates issued by a Certificate Authority or self-signed certificates. Self-signed certificates can be created by a tool of your choice. When using OpenSSL for creating the self-signed certificate, the following commands should create a valid keyfile: 

-----BEGIN CERTIFICATE-----
<br />
(base64 encoded certificate)
<br />
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
<br />
(base64 encoded private key)
<br />
-----END RSA PRIVATE KEY-----


For further information please check the manuals of the tools you use to create the certificate.
Note: the --server.keyfile option must be set if the server is started with at least one SSL endpoint.

Cafile

--server.cafile filename
This option can be used to specify a file with CA certificates that are sent to the client whenever the server requests a client certificate. If the file is specified, The server will only accept client requests with certificates issued by these CAs. Do not specify this option if you want clients to be able to connect without specific certificates.
The certificates in filename must be PEM formatted.
Note: this option is only relevant if at least one SSL endpoint is used.

SSL protocol

--server.ssl-protocolvalue
Use this option to specify the default encryption protocol to be used. The following variants are available:

  • 1: SSLv2
  • 2: SSLv23
  • 3: SSLv3
  • 4: TLSv1
  • 5: TLSv1.2 (recommended)
    The default value is 4 (i.e. TLSv1).
    Note: this option is only relevant if at least one SSL endpoint is used.

SSL cache

--server.ssl-cache value
Set to true if SSL session caching should be used.
value has a default value of false (i.e. no caching).
Note: this option is only relevant if at least one SSL endpoint is used, and only if the client supports sending the session id.

SSL options

--server.ssl-options value
This option can be used to set various SSL-related options. Individual option values must be combined using bitwise OR.
Which options are available on your platform is determined by the OpenSSL version you use. The list of options available on your platform might be retrieved by the following shell command: 

 > grep "#define SSL_OP_.*" /usr/include/openssl/ssl.h
<br />
 #define SSL_OP_MICROSOFT_SESS_ID_BUG                    0x00000001L
 #define SSL_OP_NETSCAPE_CHALLENGE_BUG                   0x00000002L
 #define SSL_OP_LEGACY_SERVER_CONNECT                    0x00000004L
 #define SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG         0x00000008L
 #define SSL_OP_SSLREF2_REUSE_CERT_TYPE_BUG              0x00000010L
 #define SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER               0x00000020L
 ...


A description of the options can be found online in the OpenSSL documentation
Note: this option is only relevant if at least one SSL endpoint is used.

SSL cipher

--server.ssl-cipher-list cipher-list
This option can be used to restrict the server to certain SSL ciphers only, and to define the relative usage preference of SSL ciphers.
The format of cipher-list is documented in the OpenSSL documentation.
To check which ciphers are available on your platform, you may use the following shell command: 

> openssl ciphers -v
<br />
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
...


The default value for cipher-list is “ALL”.
Note: this option is only relevant if at least one SSL endpoint is used.

Backlog size

--server.backlog-size
Allows to specify the size of the backlog for the listen system call The default value is 10. The maximum value is platform-dependent. Specifying a higher value than defined in the system header’s SOMAXCONN may result in a warning on server start. The actual value used by listen may also be silently truncated on some platforms (this happens inside the listen system call).

Disable server statistics

--server.disable-statistics value

If this option is value is true, then ArangoDB’s statistics gathering is turned off. Statistics gathering causes regular CPU activity so using this option to turn it off might relieve heavy-loaded instances. Note: this option is only available when ArangoDB has not been compiled with the option --disable-figures.

Session timeout

--server.session-timeout value
The timeout for web interface sessions, using for authenticating requests to the web interface (/_admin/aardvark) and related areas.
Sessions are only used when authentication is turned on.

Foxx queues

--server.foxx-queues flag
If true, the Foxx queues will be available and jobs in the queues will be executed asynchronously.
The default is true. When set to false the queue manager will be disabled and any jobs are prevented from being processed, which may reduce CPU load a great deal.

Foxx queues poll interval

--server.foxx-queues-poll-interval value
The poll interval for the Foxx queues manager. The value is specified in seconds. Lower values will mean more immediate and more frequent Foxx queue job execution, but will make the queue thread wake up and query the queues more often. When set to a low value, the queue thread might cause CPU load.
The default is 1 second. If Foxx queues are not used much, then this value may be increased to make the queues thread wake up less.

Directory

--database.directory directory
The directory containing the collections and datafiles. Defaults to /var/lib/arango. When specifying the database directory, please make sure the directory is actually writable by the arangod process.
You should further not use a database directory which is provided by a network filesystem such as NFS. The reason is that networked filesystems might cause inconsistencies when there are multiple parallel readers or writers or they lack features required by arangod (e.g. flock()).
directory
When using the command line version, you can simply supply the database directory as argument.

Examples 

> ./arangod --server.endpoint tcp://127.0.0.1:8529 --database.directory /tmp/vocbase

Journal size


--database.maximal-journal-size size
Maximal size of journal in bytes. Can be overwritten when creating a new collection. Note that this also limits the maximal size of a single document.
The default is 32MB.

Wait for sync

--database.wait-for-sync boolean
Default wait-for-sync value. Can be overwritten when creating a new collection.
The default is false.

Force syncing of properties

--database.force-sync-properties boolean
Force syncing of collection properties to disk after creating a collection or updating its properties.
If turned off, no fsync will happen for the collection and database properties stored in parameter.json files in the file system. Turning off this option will speed up workloads that create and drop a lot of collections (e.g. test suites).
The default is true.

Disable AQL query tracking

--database.disable-query-tracking flag
If true, the server’s query tracking feature will be disabled by default.
The default is false.

Throw collection not loaded error

--database.throw-collection-not-loaded-error flag
Accessing a not-yet loaded collection will automatically load a collection on first access. This flag controls what happens in case an operation would need to wait for another thread to finalize loading a collection. If set to true, then the first operation that accesses an unloaded collection will load it. Further threads that try to access the same collection while it is still loading will get an error (1238, collection not loaded). When the initial operation has completed loading the collection, all operations on the collection can be carried out normally, and error 1238 will not be thrown.
If set to false, the first thread that accesses a not-yet loaded collection will still load it. Other threads that try to access the collection while loading will not fail with error 1238 but instead block until the collection is fully loaded. This configuration might lead to all server threads being blocked because they are all waiting for the same collection to complete loading. Setting the option to true will prevent this from happening, but requires clients to catch error 1238 and react on it (maybe by scheduling a retry for later).
The default value is false.

AQL Query caching mode

--database.query-cache-mode
Toggles the AQL query cache behavior. Possible values are:

  • off: do not use query cache
  • on: always use query cache, except for queries that have their cache attribute set to false
  • demand: use query cache only for queries that have their cache attribute set to true set

AQL Query cache size

--database.query-cache-max-results
Maximum number of query results that can be stored per database-specific query cache. If a query is eligible for caching and the number of items in the database’s query cache is equal to this threshold value, another cached query result will be removed from the cache.
This option only has an effect if the query cache mode is set to either on or demand.

Index threads

--database.index-threads
Specifies the number of background threads for index creation. When a collection contains extra indexes other than the primary index, these other indexes can be built by multiple threads in parallel. The index threads are shared among multiple collections and databases. Specifying a value of 0 will turn off parallel building, meaning that indexes for each collection are built sequentially by the thread that opened the collection. If the number of index threads is greater than 1, it will also be used to built the edge index of a collection in parallel (this also requires the edge index in the collection to be split into multiple buckets).

V8 contexts

--server.v8-contexts number
Specifies the number of V8 contexts that are created for executing JavaScript code. More contexts allow execute more JavaScript actions in parallel, provided that there are also enough threads available. Please note that each V8 context will use a substantial amount of memory and requires periodic CPU processing time for garbage collection.

Garbage collection frequency (time-based)

--javascript.gc-frequency frequency
Specifies the frequency (in seconds) for the automatic garbage collection of JavaScript objects. This setting is useful to have the garbage collection still work in periods with no or little numbers of requests.

Garbage collection interval (request-based)

--javascript.gc-interval interval
Specifies the interval (approximately in number of requests) that the garbage collection for JavaScript objects will be run in each thread.

V8 options

--javascript.v8-options options
Optional arguments to pass to the V8 Javascript engine. The V8 engine will run with default settings unless explicit options are specified using this option. The options passed will be forwarded to the V8 engine which will parse them on its own. Passing invalid options may result in an error being printed on stderr and the option being ignored.
Options need to be passed in one string, with V8 option names being prefixed with double dashes. Multiple options need to be separated by whitespace. To get a list of all available V8 options, you can use the value ”--help” as follows:

--javascript.v8-options "--help"


Another example of specific V8 options being set at startup: 

--javascript.v8-options "--harmony --log"


Names and features or usable options depend on the version of V8 being used, and might change in the future if a different version of V8 is being used in ArangoDB. Not all options offered by V8 might be sensible to use in the context of ArangoDB. Use the specific options only if you are sure that they are not harmful for the regular database operation.

❮  Server Configuration

© ArangoDB - the native multi-model NoSQL database