Answers.Body: <p>It depends on your security and privacy requirements. I agree with Pete that for CiviCRM to work most simply, install it on your public facing CMS.</p>
  
  <p>You should realize however, that from a security and privacy viewpoint this is not the most secure option. If that is important to you, you should install CiviCRM on a separate server. However, that does mean that you have to think a little on the communication between your public website and CiviCRM. You can use the REST API to communicate with the CiviCRM server from your public website but is does mean you have to do some coding in your website forms. Again, it depends on your requirements.</p>
  
  <p>Hope this helps!</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-25T13:10:40.407Z
Answers.Text: Are you saying the most secure option is Standalone CiviCRM?
Answers.UserDisplayName: KarinG - Semper IT
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-25T13:39:54.917Z
Answers.Text: Or are you saying if you have a Wordpress public (example.org) site -> have a separate Drupal/CiviCRM (secure.example.org)
Answers.UserDisplayName: KarinG - Semper IT
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-25T15:13:54.933Z
Answers.Text: The latter! So have a separate Drupal/CiviCRM. Having them on one is a bit like having your gold room next to the public entrance?
Answers.UserDisplayName: ErikH - CiviCooP
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-25T15:30:47.933Z
Answers.Text: What about webform_civicrm module on a Drupal/CiviCRM -> would you not want to leverage that?
Answers.UserDisplayName: KarinG - Semper IT
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-26T06:55:12.987Z
Answers.Text: That is a choice we usually explain to the customer? If they want the most secure set up they loose Webform CiviCRM. It is a question of priorities. But there is https://github.com/CiviMRF/cmrf_core. Some of our customers prefer the server separation and specific forms.
Answers.UserDisplayName: ErikH - CiviCooP
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-26T11:34:58.940Z
Answers.Text: Of course the most secure setup would be to go back to on-premise desktop CRM installs; I think the key point if you engage webform_civicrm eg is to ensure your Drupal is at the same level of security as your CiviCRM - down to every single module one is considering to add. It's the weakest link that will provide a way in;
Answers.UserDisplayName: KarinG - Semper IT
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-26T13:06:47.590Z
Answers.Text: The issue we face a lot of time is also that we need quite a few extensions. And the user really then should test the complete processes everytime a Drupal security update is installed. So separating is usually the best option for the bigger customers we have.
Answers.UserDisplayName: ErikH - CiviCooP
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-25T08:06:12.133Z
Answers.LastActivityDate: 2017-09-25T08:06:12.133Z
Answers.UserDisplayName: ErikH - CiviCooP
Answers.Body: <p>We have several clients with a WordPress public site and a Drupal based CiviCRM.  to keep their hardworking nonprofit website staff happy.  </p>
  
  <p>If your website team insists on Wordpress and you need to take advantage of more advanced features of Drupal for things like portals and more complex integrations it can be a good compromise.  </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-26T21:18:44.420Z
Answers.Text: We use WP really just because we know it (the test CiviCRM install was very easy. Do you mean there is additional functionality if CivicCRM is based on Drupal as opposed to WP? Thx.
Answers.UserDisplayName: ToddB
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-26T23:57:18.927Z
Answers.Text: Todd,  the added functionality is with Drupal and the Drupal/Civi integration.   One example is the ability to use  CiviCRM data for Drupal views.   Both Drupal and WordPress work great for fundraising pages, even registration, and basic profile pages displayed on the website.
Answers.UserDisplayName: pkeogan - BackOffice Thinking
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-26T17:51:31.007Z
Answers.LastActivityDate: 2017-09-26T17:51:31.007Z
Answers.UserDisplayName: pkeogan - BackOffice Thinking
Answers.Body: <p>For civicrm to work best/most simply, install it on your public facing CMS.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-12-14T12:51:29.833Z
Answers.Text: It is indeed most simple but if you are subject to GDPR you have to carefully consider your security risks and document them. Placing your contact data (which are potentially privacy sensitive) on the most vulnerable part of your configuration (which is your public website) will not automatically be considered a good practise.
Answers.UserDisplayName: ErikH - CiviCooP
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-24T05:47:21.373Z
Answers.LastActivityDate: 2017-09-24T05:47:21.373Z
Answers.UserDisplayName: petednz - fuzion
Answers.Body: <p>I have a number of clients who use CiviCRM on a subdomain separately from their main content site. It has both pros and cons.</p>
  
  <p><strong>Pros:</strong></p>
  
  <p><strong><em>1. Security.</em></strong></p>
  
  <p>The main issue addresssed here is the risk of security lapses on the main site exposing CiviCRM. The reason a separate site can be more secure is that you will typically have more modules and functionality on your main site where ease of use is the primary goal, whereas with CiviCRM, security is a much higher priority. Keeping the CiviCRM site with fewer 'ease of use' tools and generally fewer functions will almost always make it more secure, at least in principle.</p>
  
  <p>Analogously - you can also provide hassle-free administrative access to designers and content editors without risk of inadvertently exposing CiviCRM.</p>
  
  <p><strong><em>2. Performance.</em></strong></p>
  
  <p>The primary use case of your main site will typically be anonymous access by visitors, whereas most of your access to CiviCRM will be authenticated. The kind of server setup for those two types of access are frequently at odds, so having them on separate servers can make for better use of machine resources. e.g. you can put your main site on a relatively inexpensive hosting service with heavy caching for anonymous visitors.</p>
  
  <p><strong>Cons:</strong></p>
  
  <p><strong><em>1. Expertise</em></strong></p>
  
  <p>Keeping internal resources to understand how multiple systems works can be a hassle and/or expensive. This is really the key driver of the decision - if you already have reasons to keep your CMS where it is, or to move it to a different CMS than your CiviCRM is on, then a split install is often a good choice.</p>
  
  <p><strong><em>2. Maintenance</em></strong></p>
  
  <p>The main other cost of the separate installs is maintenance - keeping up two sites instead of one, and updating design elements to keep the visual link between them convincing.</p>
  
  <p><strong><em>3. Server costs.</em></strong> </p>
  
  <p>Usually, two sites is going to cost more than one, but see note 2. above. Specifically - by having the lower-security functionality all together, you can use your budget more effectively, e.g. you can have a managed CiviCRM install and use more off-the-shelf (read cheap/do-it-yourself) tools for your CMS.</p>
  
  <p>I would also note that you don't need fancy machine-level integration as suggested by ErikH - you just need links back and forth, and an internal clarity that the two pieces are only loosely joined.</p>
  
  <p>For clients who are migrating from other solutions (e.g. separate online processsor services, mailing lists and event services), putting all these together on one CiviCRM site that they manage is already a huge step forward in integrating those pieces, and having that functionality relatively loosely linked to the content site is not usually a show stopper, and in some cases a desirable state.</p>
  
  <p><strong>Examples</strong></p>
  
  <p>Here are few sites that are hosting CiviCRM on a separate subsite:</p>
  
  <ol>
  <li><a href="https://www.awid.org/" rel="noreferrer">https://www.awid.org/</a></li>
  <li><a href="https://www.wildernesscommittee.org/" rel="noreferrer">https://www.wildernesscommittee.org/</a></li>
  <li><a href="http://www.fairvote.ca/" rel="noreferrer">http://www.fairvote.ca/</a> </li>
  <li><a href="http://www.patientscanada.ca/" rel="noreferrer">http://www.patientscanada.ca/</a></li>
  <li><a href="http://everdale.org/" rel="noreferrer">http://everdale.org/</a> </li>
  <li><a href="https://wildsight.ca/" rel="noreferrer">https://wildsight.ca/</a> </li>
  <li><a href="https://www.bcndp.ca/" rel="noreferrer">https://www.bcndp.ca/</a></li>
  <li><a href="https://www.kairoscanada.org/" rel="noreferrer">https://www.kairoscanada.org/</a></li>
  </ol>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-25T16:35:28.827Z
Answers.Text: Thank you so much for the comprehensive answer, great pros/cons, and examples, this is extremely helpful. The integration between www.awid.org and secure.awid.org (and similiarly the others) does not seem onerous, from our standpoint it would be mainly the design elements and an understanding of "what lives where". Security is a major issue and the point about vulnerabilities of other plug-in is a great one. Many thanks for your help!
Answers.UserDisplayName: ToddB
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-26T07:07:01.803Z
Answers.Text: Thanks @Alan. I was too quick, some of our larger customers prefer to have specific API requests with the REST and separated CiviCRM / public website. But there are certainly other solutions as you pointed out.
Answers.UserDisplayName: ErikH - CiviCooP
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-25T15:12:13.670Z
Answers.LastActivityDate: 2017-09-26T16:45:32.857Z
Answers.LastEditDate: 2017-09-26T16:45:32.857Z
Answers.UserDisplayName: Alan Dixon
Body: <p>Is there a best practice as to whether CiviCRM should be installed on its own site, separate from the public site or as part of the public site?</p>
  <p>I think of our internal users doing mailings etc and it doesn’t “feel right” for them to do this on  the CMS for our public-facing site, but at the same time we want to allow self-service contributions and event registrations.</p>
  <p>Is there any issue to link across sites (for example link public site to membership form served on CiviCRM)? Or is that just a pain.</p>
  <p>I’m afraid to just go ahead and install CiviCRM on our production public site. We use WP fwiw.</p>
  <p>Appreciate any advice.</p>
  
Tags: <wordpress><installation><best-practice><administer>
Title: Separate sites for CiviCRM and public site?
ThreadText: # Separate sites for CiviCRM and public site?
  
  (Asked by: username_0 on 2017-09-24)
  
  Is there a best practice as to whether CiviCRM should be installed on its own site, separate from the public site or as part of the public site?
  
  I think of our internal users doing mailings etc and it doesn’t “feel right” for them to do this on the CMS for our public-facing site, but at the same time we want to allow self-service contributions and event registrations.
  
  Is there any issue to link across sites (for example link public site to membership form served on CiviCRM)? Or is that just a pain.
  
  I’m afraid to just go ahead and install CiviCRM on our production public site. We use WP fwiw.
  
  Appreciate any advice.
  
  **Tags:** wordpress, installation, best-practice, administer
  
  
  ---
  
  ## 4 answers
  
  ### Answer by username_5 on 2017-09-25. Score: 8 | Accepted answer
  
  I have a number of clients who use CiviCRM on a subdomain separately from their main content site. It has both pros and cons.
  
  **Pros:**
  
  ***1. Security.***
  
  The main issue addresssed here is the risk of security lapses on the main site exposing CiviCRM. The reason a separate site can be more secure is that you will typically have more modules and functionality on your main site where ease of use is the primary goal, whereas with CiviCRM, security is a much higher priority. Keeping the CiviCRM site with fewer 'ease of use' tools and generally fewer functions will almost always make it more secure, at least in principle.
  
  Analogously - you can also provide hassle-free administrative access to designers and content editors without risk of inadvertently exposing CiviCRM.
  
  ***2. Performance.***
  
  The primary use case of your main site will typically be anonymous access by visitors, whereas most of your access to CiviCRM will be authenticated. The kind of server setup for those two types of access are frequently at odds, so having them on separate servers can make for better use of machine resources. e.g. you can put your main site on a relatively inexpensive hosting service with heavy caching for anonymous visitors.
  
  **Cons:**
  
  ***1. Expertise***
  
  Keeping internal resources to understand how multiple systems works can be a hassle and/or expensive. This is really the key driver of the decision - if you already have reasons to keep your CMS where it is, or to move it to a different CMS than your CiviCRM is on, then a split install is often a good choice.
  
  ***2. Maintenance***
  
  The main other cost of the separate installs is maintenance - keeping up two sites instead of one, and updating design elements to keep the visual link between them convincing.
  
  ***3. Server costs.***
  
  Usually, two sites is going to cost more than one, but see note 2. above. Specifically - by having the lower-security functionality all together, you can use your budget more effectively, e.g. you can have a managed CiviCRM install and use more off-the-shelf (read cheap/do-it-yourself) tools for your CMS.
  
  I would also note that you don't need fancy machine-level integration as suggested by ErikH - you just need links back and forth, and an internal clarity that the two pieces are only loosely joined.
  
  For clients who are migrating from other solutions (e.g. separate online processsor services, mailing lists and event services), putting all these together on one CiviCRM site that they manage is already a huge step forward in integrating those pieces, and having that functionality relatively loosely linked to the content site is not usually a show stopper, and in some cases a desirable state.
  
  **Examples**
  
  Here are few sites that are hosting CiviCRM on a separate subsite:
  
  1. <https://www.awid.org/>
  2. <https://www.wildernesscommittee.org/>
  3. <http://www.fairvote.ca/>
  4. <http://www.patientscanada.ca/>
  5. <http://everdale.org/>
  6. <https://wildsight.ca/>
  7. <https://www.bcndp.ca/>
  8. <https://www.kairoscanada.org/>
  
  > **Comments:**
  > **username_0**: Thank you so much for the comprehensive answer, great pros/cons, and examples, this is extremely helpful. The integration between www.awid.org and secure.awid.org (and similiarly the others) does not seem onerous, from our standpoint it would be mainly the design elements and an understanding of "what lives where". Security is a major issue and the point about vulnerabilities of other plug-in is a great one. Many thanks for your help!  
  > **username_1**: Thanks @Alan. I was too quick, some of our larger customers prefer to have specific API requests with the REST and separated CiviCRM / public website. But there are certainly other solutions as you pointed out.  
  
  ---
  
  ### Answer by username_1 on 2017-09-25. Score: 2
  
  It depends on your security and privacy requirements. I agree with Pete that for CiviCRM to work most simply, install it on your public facing CMS.
  
  You should realize however, that from a security and privacy viewpoint this is not the most secure option. If that is important to you, you should install CiviCRM on a separate server. However, that does mean that you have to think a little on the communication between your public website and CiviCRM. You can use the REST API to communicate with the CiviCRM server from your public website but is does mean you have to do some coding in your website forms. Again, it depends on your requirements.
  
  Hope this helps!
  
  > **Comments:**
  > **username_2**: Are you saying the most secure option is Standalone CiviCRM?  
  > **username_2**: Or are you saying if you have a Wordpress public (example.org) site -> have a separate Drupal/CiviCRM (secure.example.org)  
  > **username_1**: The latter! So have a separate Drupal/CiviCRM. Having them on one is a bit like having your gold room next to the public entrance?  
  > **username_2**: What about webform_civicrm module on a Drupal/CiviCRM -> would you not want to leverage that?  
  > **username_1**: That is a choice we usually explain to the customer? If they want the most secure set up they loose Webform CiviCRM. It is a question of priorities. But there is https://github.com/CiviMRF/cmrf_core. Some of our customers prefer the server separation and specific forms.  
  > **username_2**: Of course the most secure setup would be to go back to on-premise desktop CRM installs; I think the key point if you engage webform_civicrm eg is to ensure your Drupal is at the same level of security as your CiviCRM - down to every single module one is considering to add. It's the weakest link that will provide a way in;  
  > **username_1**: The issue we face a lot of time is also that we need quite a few extensions. And the user really then should test the complete processes everytime a Drupal security update is installed. So separating is usually the best option for the bigger customers we have.  
  
  ---
  
  ### Answer by username_3 on 2017-09-26. Score: 1
  
  We have several clients with a WordPress public site and a Drupal based CiviCRM. to keep their hardworking nonprofit website staff happy.
  
  If your website team insists on Wordpress and you need to take advantage of more advanced features of Drupal for things like portals and more complex integrations it can be a good compromise.
  
  > **Comments:**
  > **username_0**: We use WP really just because we know it (the test CiviCRM install was very easy. Do you mean there is additional functionality if CivicCRM is based on Drupal as opposed to WP? Thx.  
  > **username_3**: Todd,  the added functionality is with Drupal and the Drupal/Civi integration.   One example is the ability to use  CiviCRM data for Drupal views.   Both Drupal and WordPress work great for fundraising pages, even registration, and basic profile pages displayed on the website.  
  
  ---
  
  ### Answer by username_4 on 2017-09-24. Score: 0
  
  For civicrm to work best/most simply, install it on your public facing CMS.
  
  > **Comments:**
  > **username_1**: It is indeed most simple but if you are subject to GDPR you have to carefully consider your security risks and document them. Placing your contact data (which are potentially privacy sensitive) on the most vulnerable part of your configuration (which is your public website) will not automatically be considered a good practise.  
  
  ---
  
  