SugarCloud Policy Guide

Overview

This guide provides information about the various policies and practices employed by SugarCRM's SaaS cloud service.

Integrating with SugarCloud

The recommended and safest mechanism for integrating with Sugar is through the use of our REST APIs. At present, we support Module Loadable Packages in our cloud environment provided they are compatible with the Package Scanner. Disabling the Package Scanner in a SugarCloud instance is strictly forbidden and constitutes a violation of the Sugar Master Subscription Agreement. It is expected that all customized files in a cloud instance are installed via Module Loader. The Sugar Support team will not execute requests to copy individual files into a cloud instance.

Note: Sugar Sell Essentials customers do not have the ability to upload custom file packages to Sugar using Module Loader.

The Package Scanner provides a mechanism to denylist certain function and method calls which cause performance problems or could potentially be used to bypass security mechanisms in the hosted environment. If you wish to deploy your customization to a cloud instance, it is imperative that you test loading it with Package Scanner enabled and work around any issues raised. You can enable Package Scanner in your local development environment by setting the following in the ./config_override.php file:

        $sugar_config['moduleInstaller']['packageScan'] = true;

For details on the Package Scanner and a listing of denylisted functions, please visit the Developer Guide specific to your version.

You should note that Sugar's cloud service does not allow the overwriting of Sugar core files with customized versions. In addition to denylisted functions, we do not allow any modules that permit arbitrary SQL commands to be run against a Sugar database. Should we find such a module, we will remove it immediately and without warning.

Additional Considerations

• When integrating with services that make use of SSL or TLS, such as LDAP or SMTP servers, certificate validation is enforced in Sugar's cloud service. Any certificates used must be issued by an industry-recognized Certificate Authority with a valid trust hierarchy.
• All inbound entryPoints must be authenticated.
• Outbound HTTP connections must have timeouts under 1 second.
• Batch API access should reuse a session rather than perform a login for every call.
• In Sugar's cloud service, Sugar is deployed with the PHP open_basedir directive set.
• This configuration setting limits which files can be accessed from PHP to a predefined list of directories.
• This is an important setting that helps to keep your data secure.
• A side effect of open_basedir is that the ability for curl to follow HTTP redirects is disabled. Attempts to set CURLOPT_FOLLOWLOCATION will cause PHP failures.
• Sugar's cloud service runs a Linux operating system with a case-sensitive file system. Developers should verify that their customizations function appropriately when case-sensitive file systems are utilized.
• Sugar's cloud service does not allow customers to relay email through SugarCRM SMTP servers. In order to configure your own SMTP servers please refer to the Configuring Your SMTP Server to Work With SugarCloud article. 
• All MySQL tables must use the InnoDB storage engine. MyISAM tables are not permitted in order to maintain data integrity.
• File names should only consist of UTF-8 characters. Non-UTF-8 characters in file names are not supported.
• Sugar's cloud service does not enable support for htaccess. As such, no changes to htaccess rules are permitted in Sugar's cloud.
• Scheduled jobs within a cloud instance are limited to a maximum runtime of 30 minutes.

Enforced Configuration Parameters

The following configuration parameters are enforced in Sugar's cloud service for performance and security reasons. Should you require a setting to be temporarily changed on a cloud production environment, you must open a support case. To change any of these default settings on a backup or sandbox environment, you must be a developer with access to the config.php file. To see a description of the setting as well as other potential values, click on the parameter name in the table below.

Migration Procedure

In addition to Module Loader, the Package Scanner is also used during the migration procedure. When an on-site instance is migrated to Sugar's cloud, the following procedure is followed:

• Only currently supported versions of Sugar can be migrated to Sugar's cloud service. For the current list of supported software, consult the list of supported versions. If you are running an unsupported version of Sugar, you will need to upgrade to a supported version before providing the required files and database to our team for migration.
• All backups must consist of the MySQL dump and an accompanying file system in TAR format. For instructions on creating backups, refer to the Recommended Backup Procedure section of this documentation.
• The customer or partner should open a support case to provide an FTP site to upload the customer's instance and coordinate the migration process. We require at least seven (7) calendar days advance notice for a requested migration to ensure the desired date and time can be accommodated. This notice should be provided in the form of a support case.
• When requesting a migration, we ask you to provide the following details so that we can ensure the appropriate resources are allocated to your SugarCloud instance:
  • Instance total file size
  • Instance total database size
  • Total active users in the instance and estimated maximum concurrent users in the instance
  • Primary business use(s) for the instance (e.g., sales, call center, marketing campaigns, etc.)
  • Integrations installed on the instance
  • Description of any external services connecting to the application via API
• Once the FTP account is provided, the instance files and the database should be uploaded at the desired date and time.
• Sugar performs several tasks with the provided files:
• All instance core files are replaced with stock versions.
• Config values located in ./config.php and ./config_override.php are replaced to reflect values required by Sugar's cloud service. For more information, please refer to the Enforced Configuration Parameters section of this documentation.
• All non-core files are scanned using the latest version of the Package Scanner.
• If any files are found that do not pass the Package Scanner, the migration will be rejected. Upon rejection, the case is updated to indicate the reason for rejection. The customer should correct the issue and upload a new backup.
• If the instance is not on our most recent release and it passes the upgrade health check, the instance will be upgraded to the latest version of Sugar. If the instance does not pass health check, we may require action to be taken to resolve issues blocking the upgrade before finalizing the requested migration.
• Full-text search will be configured and a full system index will be triggered.

Recommended Backup Procedure

Migrating a Sugar instance from on-site to Sugar's cloud service is a straightforward process. Simply download the Sugar Instance Packager from Github and run the following command, replacing INSTANCE_NAME with the name of your SugarCloud instance (e.g., mysugarinstance) and SUGARDIR with the directory that contains your on-site Sugar instance: 

        ./packager.php --name INSTANCE_NAME SUGARDIR

Once the packager is done processing, you can view the contents of the zip file to confirm that the packaging was successful with the following command, again replacing INSTANCE_NAME with the name of your SugarCloud instance (e.g., mysugarinstance.zip):

        unzip -l INSTANCE_NAME.zip | less

Logging

Logging can dramatically affect performance, and for instances running in Sugar's cloud, we intentionally restrict the verbosity of logging to the fatal level and above to mitigate those performance impacts. This setting means that only fatal and security errors are captured. It is imperative that your integrations do not log anything but fatal and security errors at their respective log level. Please note that the Logger Settings panel in Admin > System Settings is not available for instances hosted on Sugar's cloud service.

Should you require a log level to be temporarily changed on a cloud production environment to debug an issue, you must open a support case. Running instances in a logging mode more verbose than fatal is expressly forbidden in Sugar's cloud environment for performance reasons. Please note that it is also forbidden for integrations to change the log level directly.

SugarCloud customers can generate PHP error logs and access logs via the SugarCloud Insights page.

File System and Database Size Limits

Customers with instances hosted in Sugar's cloud environment are subject to file system (FS) and database (DB) storage limits depending on the product(s) (e.g., Sugar Serve) their organization has purchased from SugarCRM. The maximum amount of Managed Storage allowance for your SugarCloud subscription is divided between the database and files belonging to the main production instance plus any of your Sugar-hosted test instances (i.e., sandboxes). SugarCloud customers can monitor their instance's file system and database storage usage via Admin > SugarCloud Insights.

For customers that purchase Sugar products after February 1, 2022, the maximum amount of file system and database storage allowances for each product are as follows:

¹ Managed Storage limits apply as a cumulative total across all production and sandbox instances. Additional storage can be purchased.
² Sugar Sell Essentials customers can purchase additional managed storage per user or upgrade to Sugar Sell Advanced. Please contact us for more information. 

To calculate the total amount of Managed Storage allowance for your Sugar product, take the base storage limit (e.g., 15 GB) plus an additional X GB (e.g., 0.25) for each user seat purchased for your SugarCRM subscription. Please refer to the following examples for more information:

Sugar Sell Advanced (Single License)

If your organization purchased Sugar Sell Advanced with 24 user seats, your total file system and database storage limits will be calculated as follows:

• File System (FS) Storage: 15 GB + (24 x 0.25 GB per user) = 21 GB
• Database (DB) Storage: 15 GB + (24 x 0.25 GB per user) = 21 GB

Sugar Sell Premier + Sugar Serve (Multi-license)

If your organization purchased Sugar Sell Premier with 40 user seats and Sugar Serve with 20 user seats, your total file system and database storage limits will be calculated as follows:

• File System (FS) Storage:  
  • Sell Premier: 30 GB + (40 x 0.5 GB per user) = 50 GB
  • Sugar Serve: 15 GB + (20 x 0.25 GB per user) = 20 GB
  • Total File System Storage: 70 GB
•  Database (DB) Storage:
  
  • Sell Premier: 30 GB + (40 x 0.5 GB per user) = 50 GB
  • Sugar Serve: 15 GB + (20 x 0.25 GB per user) = 20 GB
  • Total Database Storage: 70 GB

For more information on the file system and database storage allowances for each Sugar product (e.g., Sugar Sell Advanced, Sugar Serve) and how the managed storage gets calculated, refer to this SugarClub blog post.

We measure storage utilization as follows:

• File system and database storage amounts are allocated and measured separately. So, the total file system and database-managed storage used across your main production instance plus all of your Sugar-hosted test instances (i.e., sandboxes) count towards your SugarCloud managed storage limits.
• Should the sum of the database storage or file system storage exceed the licensed amount of managed storage, the customer and/or Sugar partner will be contacted. An automated quarter-in-arrears invoice will be sent and customers will be given the opportunity to purchase additional managed storage at a discounted price.

For more information on managing your storage usage, refer to the SugarCloud Managed Storage Limits page.

Database Update Requests

SugarCloud customers do not have direct access to the database supporting their instance, and it is forbidden to install any utility which circumvents this restriction. Occasionally, there may be a need for direct database queries to be run against a cloud instance, and if this is needed, please open a support case. When opening a case, please observe the following guidelines for these types of requests:

• It is the responsibility of the customer and/or partner to develop the desired database queries for the Sugar Support team to run.
• Requests should be submitted a minimum of 1 business day before the request needs to be completed. Depending on the volume of database queries that need to be performed, additional lead time may be necessary to complete the request.
• All database queries should be submitted in a .sql file attached as a note to the case, or if larger in size, via an FTP account that will be provided by Sugar Support. Please archive any .sql file larger than 1 MB. We will not accept files hosted on an external FTP account or URL.
• Recurring requests will not be accepted as these requests should leverage our supported APIs to complete.
• Please indicate the nature of the database queries the Sugar Support team is expected to perform:
  • UPDATE, INSERT, DELETE, and/or TRUNCATE statements are the only queries the Sugar Support team will perform.
  • Please indicate if any of the statements involve table joins as that will require additional analysis to ensure they are optimized and will not impact server performance.
• Sugar's cloud service does not support using custom database triggers or stored procedures, and any requests to perform queries creating these properties will be rejected.

Rate Limits

Activities within a cloud instance are expected to be performant and not exceed a maximum number of requests per second to ensure a stable environment. SugarCRM reserves the right to block traffic to a cloud instance when one or both of the following scenarios are impacting the stability of Sugar's cloud environment:

• Traffic in excess of 20 requests per second
• Inefficient requests (e.g., non-optimized database queries, unsupported APIs, etc.)
  • SELECT queries will be terminated after 120 seconds

In the event that SugarCRM detects one of the above scenarios impacting your instance, the following actions will be taken:

1. Traffic from the offending IP address(es) to Sugar's cloud environment will be temporarily blocked
2. A support case detailing the reasons for the restriction will be opened under your account if one does not already exist
3. The Sugar Support team will contact you to advise of the temporary traffic restriction and work with you to resolve the issue
4. Once you confirm the traffic issue to be remedied, the temporary restriction will be lifted and traffic will be closely monitored to ensure no recurrence of the behavior

In the event that you expect to perform a temporary action that would exceed 20 requests per second or you expect your traffic to exceed this rate on an ongoing basis, we require advance notice of the action as follows:

• A case is created with the following information a minimum of 7 calendar days before the increased activity is to take place:
• Start date and time of the activity and its expected duration
• Direct phone and email contact information for the individual coordinating or performing the activity 
• Specific details of the activity including an advanced agreement on limits for requests per second, concurrency, and the originating IP address(es) of the activity
• Details of any external integrations to be utilized 
• During the activity period, SugarCRM staff will monitor the database and web servers for potential issues.
• Should issues arise, our staff will contact the individual performing the activity and ask them to immediately cease.

Outbound Network Restrictions

In order to promote a secure environment for SugarCloud customers, outbound network traffic is restricted to only allow connections to specific ports and common services:

If you have a specific use case requiring access to a port or service not listed above, please create a Support case outlining the details for review by our Cloud Operations team.

Load Testing

Load testing of a cloud instance is permitted only if the following conditions are met:

• A case is created with the following information a minimum of 7 calendar days before the load test is to take place:
• Load test date and time
• Direct phone and email contact information for the individual performing the testing
• Specific details of the test, including an advanced agreement on limits for requests per second, concurrency, and the specific workflows to be tested
• Details of any external integrations to be tested
• During the load testing, SugarCRM staff will monitor the database and web servers for potential issues.
• Should issues arise, our staff will contact the individual performing the load test and ask them to immediately cease.

No load testing will be permitted without explicit, written sign-off from Sugar Support. In addition to load testing, you are required to notify us of any expected, significant upticks in general usage, which is defined as an increase of more than 10%.

Penetration Testing

Penetration testing of a cloud instance is permitted only if the following conditions are met:

• A case is created with the following information a minimum of 7 calendar days before the penetration test is to take place:
• Penetration test date and time
• Direct phone and email contact information for the individual performing the testing
• Agreement to share the results with SugarCRM at the conclusion of the penetration test
• Agreement that the results of the test are bound by our NDA and are non-disclosable to any other parties
• During the penetration testing, SugarCRM staff will monitor the database and web servers for potential issues.
• Should issues arise, our staff will contact the individual performing the penetration test and ask them to immediately cease.

No penetration testing will be permitted without an explicit, written sign-off from Sugar Support. In addition to penetration testing, you are required to notify us of any expected, significant upticks in general usage, which is defined as an increase of more than 10%.

Sandbox Policy

Cloud sandboxes will only be provisioned for customers with valid sandbox licenses. Depending on your Sugar product, a certain number of sandboxes may already be included. Should you require additional sandboxes, they must be purchased through the orders desk. If your subscription includes a sandbox, we do not automatically provision the sandbox instance. Please file a support case to have a permanent sandbox created for your instance. For more information on SugarCloud sandbox allowances and how to request a cloud-hosted sandbox, refer to the SugarCloud Sandboxes page.  

By default, cron jobs are not set to run on sandbox instances to avoid scenarios where the sandbox instance executes a scheduled job (e.g., inbound email retrieval) that should have been processed by the customer's production instance.

As a reminder, the file and database storage used by a sandbox is counted toward a customer's overall cloud storage limit.

SugarCloud Communications

For critical events such as major upgrades and maintenance windows, SugarCRM sends an email alert to all administrative users with a valid email address configured in the SugarCloud instance. SugarCloud customers can specify additional email addresses for these alerts so that any non-admin users (e.g., Sugar partner, IT team members, sales managers) can stay up-to-date on key events without taking up an administrative license in their instance.

Use the following steps to manage the email list of individuals that should receive critical SugarCloud service notifications:

1. Navigate to Admin > SugarCloud Insights in your Sugar instance.
2. Click the Notification Settings tab on the SugarCloud Insights page.
3. Enter the appropriate email addresses in the Email Address field then click "Add". To remove any existing email addresses, click the Remove link to the far right of the specific email address.
   Note: Do not add email addresses for any Sugar administrators as they are notified by default.
   

Upgrade Policy

SugarCRM provides seven days of notice for major upgrades. Major upgrades are any upgrade in which either of the first two digits of the version number will change. In SugarCloud, each quarterly release is considered a major upgrade. We will automatically schedule your instance upgrade within 30 days of a major release. An email is sent out seven days in advance of the upgrade to all configured email addresses as described in the SugarCloud Communications section of this page. If the proposed upgrade date and time are not amenable to your business needs, you may request an alternative day that occurs no later than two months from the release date. Upgrade extensions must be requested by opening a support case. At this time, it is not possible to opt-out of an upgrade as we ensure a stable, common environment for all customers hosted on Sugar's cloud service. 

Please note that SugarCRM requires all SugarCloud customer instances to run on a supported version of Sugar. When running a supported version, customers may still be required to upgrade to a more recent version of Sugar to remain in Sugar's cloud environment. These upgrade requirements ensure we are able to prevent exposure to known security vulnerabilities and maintain an optimal hosting environment for our customers.

Instances with no configured email addresses set up will not receive prior notice for upgrades. Minor upgrades (i.e. upgrades for which neither of the first two version digits changes), do not trigger a notification.

All upgrades are processed within an 8-hour window depending on where your Sugar instance is hosted:

Customers may request a custom 8-hour upgrade window by opening a support case.

For more information, please refer to the Upgrading SugarCloud Instances article.

Backup Storage Policy

SugarCRM backs up all production instances on Sugar's cloud service every 24 hours. All active cloud instances are backed up daily, and each backup is retained for 30 days. In addition, backups are taken immediately preceding upgrades and are also retained for a 30-day period. Please note that backups cannot be made available for instances hosted in SugarCRM's demo environment, and daily backups of these instances are not performed.

Sugar Support can schedule and provide backups on a one-time or recurring (e.g., daily) basis, based on your organization's needs. To request backups for your instance, you must file a case with the Sugar Support team. Please note that uploaded files are not included in the backups by default. If you would like to have your uploaded files included in the backups, please put in a request with the Support team.

The backup files will be made available to access and download in the Backups section of the SugarCloud Insights page at a frequency determined by your Sugar product (e.g., Sugar Sell). For more information on the cloud backup frequency, refer to the SugarCloud Offerings page. Please note that your scheduled backups do not count against your Managed Storage allowance.

If a customer either migrates from Sugar's cloud service to an on-site deployment or allows their subscription with SugarCRM to expire, their SugarCloud instance will be archived. Once archived, a final backup of the instance will be retained for a period of 120 days at which point, the instance files and data will be completely deleted. If this instance data is needed within the 120-day timeframe, please file a support case or, if you are no longer a customer, send an email to support@sugarcrm.com to request the files. 

Security Patch and Communication Process

Upon discovering a security vulnerability in the Sugar application, a fix will be developed by our engineering department. Following the successful testing of the fix by our Quality Assurance department, a hotfix will be developed. The hotfix deployment process then begins immediately. SugarCRM's commitment is to secure all instances using Sugar's cloud service from a known vulnerability before publicly disclosing the vulnerability. 

Scheduled Maintenance

SugarCRM maintains a standard weekly maintenance window as follows:

• North America: 
  • Standard Time: On Sunday 02:00 UTC to 11:00 UTC
  • Daylight Saving Time: On Sunday 01:00 UTC to 10:00 UTC
• EMEA: On Saturday 20:00 UTC - Sunday 05:00 UTC
• APAC: On Saturday 16:00 UTC to Sunday 01:00 UTC 

Activities that are performed in this weekly window fall into one of two categories: routine maintenance or platform upgrades.

Routine Maintenance

For routine maintenance, which involves downtime, an email message will be sent to the cloud communication recipients of the affected instances 3 days prior to the event. Examples of routine maintenance would be operating system or platform patches, server resizing, migrating your SugarCloud instance to a new cloud stack, etc.

Platform Upgrades

Sugar occasionally upgrades the major versions of the components necessary to run Sugar such as MySQL, PHP, Elasticsearch, etc. For any major platform upgrades, two email communications will be sent to cloud communication recipients of affected instances. The first communication will be a minimum of 2 weeks before the platform upgrades are initiated in Sugar's cloud. The purpose of this communication is to provide a general window on when to expect the upgrade to occur so that any necessary preparations can be made. The second communication will be 3 days prior to the event. 

Unscheduled Maintenance and Downtime

In extreme circumstances, we may determine that the best course of action to address an issue impacting the stability or security of the SugarCloud requires downtime outside of our weekly maintenance window. In these cases, we make every effort to provide as much advance notice as possible to our customers via email communications and to our community. Customers can always check the current SugarCloud server status at http://status.cloud.sugarcrm.com. Details on the current status are updated in near real-time.