System Architecture & Infrastructure

Hosting for OpenApply moved in August 2013 to new infrastructure in order to provide better reliability, improved security, better redundancy and a high availability (HA) architecture.

Hosting Facilities

OpenApply servers are hosted at the iWeb data center in Montreal, Quebec (Canada). This secure facility is protected by the cutting-edge access control systems with dedicated facility management spaces. Only iWeb authorized technical staff can physically access servers and only do so under our guidance. The servers at iWeb all run redundant power supplies and redundant fiber-optic network links. Our backups are hosted inside Amazon Web Services using Simple Storage Service (S3).


We redundantly store all application data on slave-master replicated servers using an internal, private network. We stream files “live” from our master storage to our secondary storage using back-to-back ten gigabit fiber-optic cables.

Since our systems are designed with redundancy and performance in mind, the OpenApply main database is stored using RAID 1 and SSD disks. This way, the master storage can fail at any time, and a quick recovery brings the duplicate database into service quickly and with zero data loss.

Data & File Backups

In addition to database redundancy, we store files on redundant backups. We back up files daily using incremental file versioning inside of Amazon Web Services’ S3. Versioning files enables us to recover files from accidental deletion in the main storage system.

We keep a history of all files indefinitely, allowing us to retrieve files deleted up to one year ago. All backup transfers between servers use industry-standard SSH encrypted connections.

SSL, Passwords & PCI-Compliance

256-bit SSL (https) is enabled by default on all user accounts. Account passwords are encrypted using one-way salted hashes. All credit card payments are processed with full PCI-compliance by Stripe Inc.

Regularly-updated Infrastructure

Our servers running Ubuntu Long Term Support versions 14.04 and 16.04 are consistently patched to use the latest updates. We regularly review and apply security patches in consultation with our external security team.

24/7 Monitoring

We use Pingdom and NewRelic to monitor our infrastructure and application performance. If a server experiences an outage, our systems immediately escalate the issue to an on-call person via push notification and SMS to investigate the issue. You can monitor our historical uptime at Our SLA mandates < 300 ms application response times and our performance has been consistent with this goal since 2009.

Firewall & Security

Our iWeb servers are hosted behind a Cisco dedicated hardware firewall. Together with application security measures, we can defend against multiple forms of DDoS attack, block port scans, thwart brute force password cracking, and repel other types of malicious attacks.

Data Protection

Faria Systems Inc. complies with both the EU Safe Harbour Agreement and the Canadian Personal Information Protection and Electronic Documents Act. Our hosting facility is located in Canada at iWeb in Montreal. Under European Commission rules, Canada is treated as a jurisdiction having ‘adequate protection’. In November 2015, the European Commission ruled the EU Safe Harbour as being invalid.  In response and to provide further assurance to schools, we have entered into supplemental Data Protection agreements both with schools individually and with the IB.  Please contact us at [email protected] if you would like us to provide a supplemental Data Protection agreement with your school.

Security Policy

This Security Overview briefly describes security practices currently applied at Faria Systems.
Read our security policy

1. Development and Deployment Security

  1. Developers must follow operational security practices to ensure that their work machines and devices are not compromised.
    • All development machines are required to be password-protected and not shared between developers.
    • File system encryption is required for all developers, including contractors.
  2. All software developed by Faria Systems (‘Software’) is tracked in Git, a temper-evident version control system which works in terms of commits, set of changes over time.
    • Each commit is timestamped, marked with author information, and cryptographically signed.
    • Changing contents of a commit automatically invalidates the signature.
  3. An automatic code analysis tool, Code Climate, is invoked on every software commit submitted to GitHub. This service analyses code revisions as they are created during development, and poses alerts on potential code quality or security issues.
    • Principal developers are required to ensure that all software changes must be free of security issues, before they can be promoted to production.
  4. An automatic platform scanning tool, AppCanary, is installed on all development and production servers running our software. This tool checks third-party software packages and dependencies installed on all servers and checks for known vulnerabilities.
    • When a vulnerability is discovered, the development team is paged for resolution, which usually involves upgrading the affected packages to versions that contain fixes.
  5. Deployment of all Software is automated with scripts. During deployment, the cryptographic signature (‘SHA’) of the desired commit is used to refer to the revision desired by the principal developer and ensure that all servers in question are updated with the same revision of software.
  6. Deployment of any software to any server requires key-based authentication, where the public key of the principal developer must be verified by the destination servers. Management of public keys on servers is handled by internal systems which automatically update and remove authorized public keys from relevant servers to reflect a centrally defined access control list.
    • Manual auditing of authorized keys and access to each server is done at random intervals.

2. Operational Security

  1. All network interaction with Faria’s Software is proxied via CloudFlare, a service which provides DDoS mitigation, content acceleration and application security.
    • The origin IPs for our servers are not exposed, which lessens the risk of targeted attacks that work around CloudFlare.
    • Common attack vectors are automatically mitigated with CloudFlare’s application firewall rulesets.
  2. Traffic that passes through CloudFlare must then pass through Faria’s own Cisco firewall appliances.
  3. All production network traffic is encrypted with valid SSL Certificates. Unencrypted connections are not accepted and customers will be automatically steered towards encrypted connections.
  4. Each software project in Production is served by at least two front-end application servers. In case an investigation is required, the affected server can be pulled off-line immediately for forensic snapshotting without causing downtime.

3. Data Integrity and Recovery

  1. Use of foreign keys, constraints, and application-level validations is encouraged whenever appropriate, to ensure that data models employed by applications are well-defined and less likely to cause application issues, require manual migration, nor necessitate rework.
  2. For all projects, automatic daily database backups are kept for 90 days; weekly backups are kept forever.
  3. For each project, the principal developer periodically verifies integrity of data backups by performing restoration in a controlled environment.
  4. For each project, a Pre-Production / Support environment is available for software testing and data inspection purposes. This environment is isolated from the Production environment and ensures that revisions of Software in development do not interfere with other revisions already promoted to Production.

4. Physical and Personal Security

  1. All WiFi networks at all Faria Education Group offices are encrypted and the passwords rotated periodically.
  2. All Faria Education Group offices have working locks and alarm systems.
  3. Each Faria Education Group staff member is allocated with a commercial VPN account, to be used when connecting in public.

5. System Security

  • System installation uses hardened and patched OS Ubuntu 14.04 LTS or Ubuntu 16.04 LTS.
  • System patching is configured by Technical Operations to provide continuous protection from exploits.
  • Dedicated firewall helps block unauthorised system access.
  • All SSH connections to both production and staging use secure RSA public key authentication:
  • Password authentication is disabled on both production and staging servers to prevent attempts at brute force cracking.
  • Github provides secure Git revision control for all Faria applications. All development staff are required to subscribe to e-mail notifications and the RSS feed. This provides staff with real-time notification of production and staging deploys.
  • System uptime and performance is monitored continuously via Pingdom and NewRelic at 30 second intervals while SMS, e-mail, and push notifications are used to send alerts.

6. Local Security

  • Passwords shall be greater than 8 characters, include both upper and lower case characters, numbers, and symbols.
  • All automatic logins shall be disabled.
  • Screensavers shall be password protected (we recommend LockTight).
  • Local firewalls shall be enabled to prevent access to unauthorized services.
  • Hard disk drives shall be encrypted using FileVault or PGP whole-disk encryption.
  • Private key passphrases shall be strong, including both upper and lower case characters, number, symbols and not contain public or personal information that would be easily guessed.
  • IT systems when not within the boundaries of Faria system operations shall be secured and/or attended at all times.
  • When traveling, computers shall not be included in checked baggage.
  • When operating in public areas, IT systems shall not be left unattended.

7. Deploy Procedures for Staging

  • Please make sure that all tests pass before deploying to ensure that you are not breaking code.
  • Under no circumstances should you fork any repository without written permission.

8. Deploy Procedures for Production:

  • Please make sure that all tests pass before deploying to ensure that you are not breaking code.
  • Do not deploy to production at non-scheduled times without approval unless otherwise justified (i.e. use your professional judgment).
  • At least two staff must be online for all scheduled production deploys.
  • If you receive a downtime alert from Pingdom, you should immediately investigate to determine and rectify the issue. If it is related to a recent production deploy, you should immediately revert all changes.

9. Other

  • Do not store credit card information on our servers or accept credit card information over the phone or e-mail. All credit card payments are processed through Stripe on PCI-compliant servers.
System Diagram

OpenApply Systems Digram