{"ok": true, "next": null, "rows": [{"id": "settings:config-dir", "page": "settings", "ref": "config-dir", "title": "Configuration directory mode", "content": "Normally you configure Datasette using command-line options. For a Datasette instance with custom templates, custom plugins, a static directory and several databases this can get quite verbose: \n             datasette one.db two.db \\\n  --metadata=metadata.json \\\n  --template-dir=templates/ \\\n  --plugins-dir=plugins \\\n  --static css:css \n             As an alternative to this, you can run Datasette in  configuration directory  mode. Create a directory with the following structure: \n             # In a directory called my-app:\nmy-app/one.db\nmy-app/two.db\nmy-app/datasette.yaml\nmy-app/metadata.json\nmy-app/templates/index.html\nmy-app/plugins/my_plugin.py\nmy-app/static/my.css \n             Now start Datasette by providing the path to that directory: \n             datasette my-app/ \n             Datasette will detect the files in that directory and automatically configure itself using them. It will serve all  *.db  files that it finds, will load  metadata.json  if it exists, and will load the  templates ,  plugins  and  static  folders if they are present. \n             The files that can be included in this directory are as follows. All are optional. \n             \n                 \n                     *.db  (or  *.sqlite3  or  *.sqlite ) - SQLite database files that will be served by Datasette \n                 \n                 \n                     datasette.yaml  -  Configuration  for the Datasette instance \n                 \n                 \n                     metadata.json  -  Metadata  for those databases -  metadata.yaml  or  metadata.yml  can be used as well \n                 \n                 \n                     inspect-data.json  - the result of running  datasette inspect *.db --inspect-file=inspect-data.json  from the configuration directory - any database files listed here will be treated as immutable, so they should not be changed while Datasette is running \n                 \n                 \n                     templates/  - a directory containing  Custom templates \n                 \n                 \n                     plugins/  - a directory containing plugins, see  Writing one-off plugins \n                 \n                 \n                     static/  - a directory containing static files - these will be served from  /static/filename.txt , see  Serving static files", "breadcrumbs": "[\"Settings\"]", "references": "[]"}, {"id": "settings:id2", "page": "settings", "ref": "id2", "title": "Settings", "content": "The following options can be set using  --setting name value , or by storing them in the  settings.json  file for use with  Configuration directory mode .", "breadcrumbs": "[\"Settings\"]", "references": "[]"}, {"id": "settings:setting-publish-secrets", "page": "settings", "ref": "setting-publish-secrets", "title": "Using secrets with datasette publish", "content": "The  datasette publish  and  datasette package  commands both generate a secret for you automatically when Datasette is deployed. \n             This means that every time you deploy a new version of a Datasette project, a new secret will be generated. This will cause signed cookies to become invalid on every fresh deploy. \n             You can fix this by creating a secret that will be used for multiple deploys and passing it using the  --secret  option: \n             datasette publish cloudrun mydb.db --service=my-service --secret=cdb19e94283a20f9d42cca5", "breadcrumbs": "[\"Settings\"]", "references": "[]"}, {"id": "settings:setting-secret", "page": "settings", "ref": "setting-secret", "title": "Configuring the secret", "content": "Datasette uses a secret string to sign secure values such as cookies. \n             If you do not provide a secret, Datasette will create one when it starts up. This secret will reset every time the Datasette server restarts though, so things like authentication cookies and  API tokens  will not stay valid between restarts. \n             You can pass a secret to Datasette in two ways: with the  --secret  command-line option or by setting a  DATASETTE_SECRET  environment variable. \n             datasette mydb.db --secret=SECRET_VALUE_HERE \n             Or: \n             export DATASETTE_SECRET=SECRET_VALUE_HERE\ndatasette mydb.db \n             One way to generate a secure random secret is to use Python like this: \n             python3 -c 'import secrets; print(secrets.token_hex(32))'\ncdb19e94283a20f9d42cca50c5a4871c0aa07392db308755d60a1a5b9bb0fa52 \n             Plugin authors can make use of this signing mechanism in their plugins using the  datasette.sign()  and  datasette.unsign()  methods.", "breadcrumbs": "[\"Settings\"]", "references": "[]"}, {"id": "settings:using-setting", "page": "settings", "ref": "using-setting", "title": "Using --setting", "content": "Datasette supports a number of settings. These can be set using the  --setting name value  option to  datasette serve . \n             You can set multiple settings at once like this: \n             datasette mydatabase.db \\\n  --setting default_page_size 50 \\\n  --setting sql_time_limit_ms 3500 \\\n  --setting max_returned_rows 2000 \n             Settings can also be specified  in the database.yaml configuration file .", "breadcrumbs": "[\"Settings\"]", "references": "[]"}], "truncated": false}