Manual » Overview

Security and System Administration

Security and Credentials takes the security of your data and credentials seriously. Scriptflow will never save credentials for public graphs and the default option is to not save credentials in private graphs. Users have the option to download a json file containing a flow's credentials prior to saving the graph and have an option to load those credentials later. Scriptflow only stores credentials in a graph if the user explicitly requests it - and only for private graphs. Users can choose to save their credentials locally or with another credential management system that works with files. If users want to share credentials, it is recommended to use a secure network storage system to share files.

Credentials are defined in nodes by developers and work seamlessly for graph creators.


Cross-site scripting is a form of attack on a website where a malicious user attempts to retrieve credentials, authorization tokens, or data from unsuspecting users by writing a script that executes on a different domain. does not run graphs in the same domain as Due to the Same Origin Policy, this means that graphs do not have access to your credentials or cookies. This is similar to how JSFiddle or other online code tools run.

Note that while takes precautions to prevent these forms of attacks, users need to be careful to not blindly trust any graph and should not input their credentials for other websites into scriptflow graphs that they have not created personally or by a member of their team.

System Administration with CLI and Proxy

At times it is useful to have a single data proxy that your entire team can use to access server side data. This can be easily achieved by running the scriptflow CLI in proxy mode:

scriptflow-cli -w

You can specify host and port options by checking the cli help command:

scriptflow-cli -h

You can then tell your graph creators to setup their graph proxy to the url of the CLI proxy. There are a few things to note when doing this:

  • Your proxy server should not be open to the internet. If the user is on your internal network and uses an internal IP to connect to the proxy, the proxy should work for them. If the user is not in your internal network, then the proxy should not work for them. It is not recommended to host a proxy server open to the internet since this could be a security risk for all systems that the proxy server can access.
  • If you do not have an internal network, each user can still use their own local proxy. This is the recommended alternative as local proxies are not accessible by other users.
  • The proxy uses websockets in order to communicate with clients. This means that if you use a load balancer (like Nginx, HAProxy, or Apache) in front of your proxy, you will need to properly configure it to allow websockets (and also allow sticky sessions when load balancing).

Enterprise considerations

Hosting your own instance of allows you to keep all your flows on your own network and create private packages that only your employees can access. Private hosting is only available for enterprise plan customers.