Getting Started

We will help you to use Remote Settings in your application!

Create a new official type of Remote Settings

Basically, you will have to go through these 3 steps:

  1. Setup the Mozilla VPN
  2. Design your data model (see below) and prepare the list of colleagues that will be allowed to review your data
  3. Request the creation of your collection using this Bugzilla ticket template

Once done, you will be able to login and edit your records on the Admin UIs:

The records will then be publicly visible at https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/{collection-id}/records

Don’t hesitate to contact us (@delivery on Slack) if you’re stuck or have questions about the process!

Check out the screencast to create, request review and approve changes, or our FAQ!

Note

In order to try out changes in a real environment, you can use the STAGE instance:

In order to switch Firefox from PROD to STAGE, use the Remote Settings DevTools!

The records will be publicly visible at https://settings.stage.mozaws.net/v1/buckets/main/collections/{collection-id}/records

Note

If you simply want to play with the stack or the API, the best way to get started is probably to use our DEV server, since everyone is allowed to manipulate data on the server and the multi-signoff workflow is not enabled. Check out the dedicated tutorial!

About your data

Name your collection in lowercase with dashes (eg. public-list-suffix, examples).

The Admin UI automatically builds forms based on some metadata for your collection, namely:

  • the list of fields to be displayed as the list columns (eg. title, comment.author)
  • a JSON schema that will be render as a form to create and edit your records (see example)
  • whether you want to control the ID field or let the server assign it automatically
  • whether you want to be able to attach files on records

Note

If your client code expects to find 0 or 1 record by looking up on a specific field, you should probably use that field as the record ID. RemoteSettings("cid").get({filters: {id: "a-value"}}) will be instantaneous.

By default, all records are made available to all users. If you want to control which users should have a particular entry, you can add a filter_expression field (see target filters).

Records vs. Attachments?

Since the diff-based synchronization happens at the record level, it is recommended to keep your Remote Settings records small, especially if you update them often.

It is important to design your data layout carefully, especially if:

  • you have too many records (eg. > 2000)
  • you have big amounts of data (eg. > 1MB)
  • your data cannot be easily broken into pieces
  • your updates are likely to overwrite most of the collection content

Consider the following summary table:

Strategy Pros Cons
Many small records
  • Efficient sync
  • Easier to review changes in Admin UI
  • Costly lookups in client
  • Updates potentially harder to automate
Few big records
  • Efficient lookups in client
  • Harder to review changes within records in Admin UI
  • Memory usage in client
Attachments
  • No limit in size & format
  • No partial update
  • Packaging attachments in release binary is feasible but tedious (source)

Collection manifests

Both STAGE and PROD collections attributes and permissions are managed via YAML files in the remote-settings-permissions Github repository.

If you want to accelerate the process of getting your collection deployed or adjust its schema, in STAGE or PROD, you can open a pull-request with the collection, and the definition of {collection}-editors and {collection}-reviewers groups. Check out the existing ones that were merged.