Configuration (Local)
This page concerns running Lantern on your local computer. For more information on how to deploy Lantern on a remote server, such as a cloud VPS, please see Configuration (Remote)
Web Configuration
Before starting to use Lantern, you will need to build a configuration file. The web configuration tool is the easiest way to generate one.
When running Lantern without a configuration file, it will prompt you to visit an URL to use the configuration tool. This tool will help you quickly start running Lantern, and includes some tests to check if it is running correctly.
Note that if you are using the Docker install for Lantern, the web configuration tool will instead run and be accessible locally, by default at http://localhost:8080 .
For information on how to use this tool, please see the Web Configuration Tool section.
Manual Configuration
If you prefer to generate your own configuration file, you may do so using the format described below. We also have a few examples here.
The configuration file conforms to JSON formatting.
Basic Configuration
"maximum_disk": intThis sets the maximum disk space (in gigabytes) that Lantern is permitted to use. This is to provide a safety limit, so that if you try to cache too much locally, you won't crash Lantern and/or your server.
"location":"string"This is the path Lantern will use to store any data files. In can be on a separate drive if needed. We recommend high-speed storage for this such as an SSD or NVME drive.
Programs and Filters
This is where you set the programs Lantern will cache. You can specify any number of programs. Certain programs may not work (System, Token programs) and must be handled with runtime caching.
Note: While you can apply filters within the { } after the program public key, certain filters may result in the freshness of local data becoming undecideable, in other words, Lantern cannot know if local data is up to date or not. At this time, we don't support the use of filters. A future update to Lantern will allow more functionality here.
Runtime Behavior
This determines whether Lantern will cache any accounts that you request during runtime, that are outside of the programs you define in this configuration file.
If you set this to true, Lantern will store and keep up to date ALL accounts you request during runtime. This is a good way to keep updated data about accounts that belong to the System program, either token programs, or other very large programs.
For example, if during runtime you request 100 System program accounts, Lantern will store the data for these accounts only, and start keeping them up to date. Further requests will serve the local data instead of making an external RPC request.
Note: Keeping system or token accounts up to date can consume a lot of bandwidth! We recommend a 'Business' plan at Flux RPC.
If you cache even one system account, you'll have to receive all the updates to the system program (a lot!). Caching System or Program accounts costs about the same no matter how many you cache. There's no easy answer here, but applications that require the fastest access speeds or make a large number of repeat requests are most likely to benefit from runtime caching.
If you set this to false, it will not store any additional account data. It will simply pass any requests for new accounts to FluxRPC each time.
This is the local port that lantern will respond to requests at. It defaults to 8080, but you may set it to any available port.
These control how Lantern communicates with our server to receive updates to the Solana programs you are interested in. At this time, you should not modify these values.
This controls whether monitoring is enabled. The monitoring service pushes data out to a Grafana server. The default is False, as it very slightly slows down Lantern. It's mainly there as a tool for us to help debug any issues end-users encounter.
This sets the URL for the Grafana server that will receive data from Lantern. You must set this if monitoring is set to True.
This sets the data storage strategy used by Lantern. Valid entries are "normal" and "memory". Setting it to memory will cause Lantern to store all cached data purely in memory. In most cases, this will result in a modest performance increase. It's useful if you have memory to spare, and require the absolute maximum speed possible.
When not set, Lantern will default to "normal" mode, and store program accounts to disk.
Last updated