By default, Refacto will use an in-memory database. This means it cannot be load-balanced, and all data will be erased if the server is restarted or an update is deployed. To persist data and allow load-balancing, configure a real database:
You can specify the database connection string as:
DB_URL="mongodb://localhost:27017/refacto" ./index.jsThe URL can also contain options, such as:
DB_URL="mongodb://localhost:27017/refacto?ssl=true" ./index.jsOn macOS, MongoDB can be installed with:
brew install mongodb
brew services start mongodbOn Ubuntu, it can be installed with:
apt install mongodbThe configuration file will be created at /usr/local/etc/mongod.conf
on macOS and /etc/mongod.conf on Ubuntu.
Note: MongoDB's default security model is enough for local development, but you should lock it down further in deployments. See the security documentation for details.
Redis is also supported for persisting data, but is experimental and not recommended for production deployments.
DB_URL="redis://localhost:6379/0" ./index.jsPostgreSQL is also supported for persisting data, but is not optimised for this type of data. For small deployments, it may be easier to securely configure PostgreSQL than MongoDB.
You must create a database for Refacto to use. The schema will be auto-generated when the app starts.
DB_URL="postgresql://localhost:5432/refacto" ./index.jsYou will need a Google client ID:
- Go to https://console.developers.google.com/apis
- Create a new project (if necessary)
- In the "Credentials" screen, find the auto-generated OAuth client entry (if it was not created automatically, create one manually with "Create credentials" → "OAuth client ID")
- Record the client ID (you will not need the client secret)
- Update the authorised JavaScript origins to match your deployment.
e.g. for local testing, add
http://localhost:5000 - Update the authorised redirect URIs to the same value, with
/sso/googleappended to the end. - You may want to change the "Support email" listed under "OAuth consent screen", as this will be visible to users of your deployed app.
You can now invoke the application with the SSO_GOOGLE_CLIENT_ID
environment variable set. This applies to both local testing and
deployments. For example:
SSO_GOOGLE_CLIENT_ID="something.apps.googleusercontent.com" ./index.jsYou will need a GitHub client ID:
- Go to https://github.com/settings/applications/new
- Set the "Homepage URL" to match your deployment. e.g. for local
testing, use
http://localhost:5000 - Set the "Authorization callback URL" to the same value, with
/sso/githubappended to the end. - Record the client ID and client secret.
You can now invoke the application with the SSO_GITHUB_CLIENT_ID and
SSO_GITHUB_CLIENT_SECRET environment variables set. This applies to
both local testing and deployments. For example:
SSO_GITHUB_CLIENT_ID="idhere" SSO_GITHUB_CLIENT_SECRET="secrethere" ./index.jsYou will need a GitLab client ID:
- Go to https://gitlab.com/profile/applications
- Set the "Redirect URI" to match your deployment with
/sso/gitlabappended to the end. e.g. for local testing, this could behttp://localhost:5000/sso/gitlab - Untick the "confidential" option. You do not need to enable any scopes.
- Record the application ID (you will not need the secret).
You can now invoke the application with the SSO_GITLAB_CLIENT_ID
environment variable set. This applies to both local testing and
deployments. For example:
SSO_GITLAB_CLIENT_ID="idhere" ./index.jsTo use a self-hosted GitLab deployment, you will also need to set the auth and token info URLs:
SSO_GITLAB_AUTH_URL="https://gitlab.example.com/oauth/authorize" \
SSO_GITLAB_TOKEN_INFO_URL="https://gitlab.example.com/oauth/token/info" \
SSO_GITLAB_CLIENT_ID="idhere" \
./index.jsYou will need a Giphy API key:
- Go to https://developers.giphy.com/dashboard/?create=true
- Log in and provide an application name and description
- Record the API key.
You can now invoke the application with the GIPHY_API_KEY environment
variable set. This applies to both local testing and deployments. For example:
GIPHY_API_KEY="keyhere" ./index.jsThe haveibeenpwned password database is automatically used for checking user-provided passwords (k-Anonymity ensures no passwords are leaked to the external service).
No configuration is required.
If you wish to disable this integration, you can specify a blank URL:
PASSWORD_CHECK_BASE_URL="" ./index.js