Skip to content

All about projects

A project is one website or application in Core. It's what you create first, and it's the page you'll spend most of your time on.

Creating a project gives you a working website. Core sets up the parts underneath — where your files live, how your domain reaches them, what runs your code, and a database if the template needs one — and connects them. You don't have to know which part is which to get started.

This article explains what a project is made of, what each template sets up, what you can do from the project page, and how to import one that already exists.


Where to find projects

'Projects' is the first item in Core's main menu, and the dashboard shows how many you have. The 'Projects' page lists them all.

  • Click 'Create' to set up something new.
  • Click 'Import' to bring something that already exists under a project. See Importing what already exists.

Note that staging can only be turned on while creating the project. See Staging Environment.

Creating a project

The 'Create Project' page has three sections.

Project

  • 'Cluster' — which cluster the project runs on. Clusters that cannot host it are disabled, with the reason shown next to the name.
  • 'Name' — letters, digits, dash, underscore and spaces. Max 32 characters. A label in Core, not part of any URL.
  • 'Domain' — the domain it is served on, for example dropflix.io.

Template

Pick one tile. The template decides what Core sets up and how it is configured.

Template What Core sets up Installs the software?
'Static' Files served straight from disk, no application runtime. Nothing to install
'PHP' A PHP-FPM pool on the PHP version you pick. No
'NodeJS' A Passenger app on the Node.js version you pick. No
'WordPress' PHP, plus the WordPress cron. Yes
'Laravel' PHP, a queue worker, and a database with a user. No — bring your own code
'Craft' PHP, a queue worker, and a database with a user. No — bring your own code

A greyed-out tile means the selected cluster does not support it. Hover for what is missing, usually "Select a cluster with PHP support".

Extra fields appear depending on the tile:

  • 'PHP Version' — PHP, WordPress, Laravel, Craft.
  • 'NodeJS Version' — NodeJS.
  • 'Admin email' and 'WordPress version' — WordPress. The admin email is for the WordPress administrator account: account recovery and WordPress notifications.
  • 'Use Blitz' — Craft. Blitz is a Craft caching plugin; this adds the nginx config that serves Blitz's cached pages directly, without starting PHP.

Staging Environment

Turn on 'Create Staging Environment' for a second copy alongside production. A 'Staging Domain' field appears, pre-filled in the style of staging.dropflix.io.

This can only be set up while creating the project. To add staging later, contact Cyberfusion support.

See Staging environments and cloning.

After you click 'Create Project'

Core shows a "Creating project..." overlay while it works. Leave the page open until it finishes.

What a project contains

  • A 'Name', for your own administration.
  • A 'Template', which records what kind of website or application this is and decides what gets set up.
  • A cluster it lives on.
  • One or two environments.

An environment is one running copy of the website or application. Every project has a production environment, and can also have a staging environment.

Each environment runs under its own account, and therefore has its own files, processes and login. That is what keeps staging from touching production.

The project page

When the project has staging, a 'Production' / 'Staging' switch sits near the top of the sidebar. Most items below it follow it, so you always look at one environment at a time.

Summary

  • 'Template' — which template the project uses. WordPress projects get a 'Login' button that signs you into WordPress admin without a password.
  • 'Language' — the PHP or Node.js version. 'Change' switches version; 'Restart' restarts the pool or app.
  • 'SSL' — how many of the project's domains have a certificate. 'View' lists every domain and its status. Domains without one get a 'Request Let's Encrypt' button, which is how you turn HTTPS on after DNS points at the cluster. See Let's Encrypt certificates.
  • 'Cluster' — which cluster the project runs on.

IP Addresses

The IP addresses the project is reachable on. This is what you point DNS at.

SFTP & SSH

The login details for this environment, and where you set or disable its password. See Change or disable a UNIX user's password.

Services

  • 'Daemons' — long-running processes, such as a queue worker. See Daemons.
  • 'Crons' — scheduled commands. See All about crons.
  • 'Databases' — shown when the cluster supports MariaDB or PostgreSQL. See All about databases.
  • 'Redis' — shown when the cluster supports Redis. See All about Redis.

Logs

'Access' and 'Error' open the web server logs.

Use the error log first when a request returns a 502 or a 500.

CMS

Shown for WordPress projects and projects that have staging:

  • 'Search & Replace' — replaces a string throughout the environment's database. Usual reason: a domain change, where the old domain is still stored in thousands of rows.
  • 'Clone' — copies staging over production. See Staging environments and cloning.

Other

  • 'Backups' — the file and database archives of the environment: create, browse, download and restore. Shown once the environment has a Borg repository. See Working with your backups.
  • 'Current Requests' — the requests being handled right now. Useful when things are slow.
  • 'Malware' — files the daily malware scan flagged. See Malware scanning and Clean up after a hack.
  • 'Settings' — 'Update document root' and 'Update PHP settings'.
  • 'Advanced' — tiles for the underlying objects, each with a 'Manage' button. The bridge from the project to the UNIX user, virtual host, and FPM pool or Passenger app.

Craft projects also get a 'Craft' item for the Blitz cache: 'Enable', 'Disable', and 'Customise config' to edit the nginx snippet Blitz uses.

Importing what already exists

On the 'Import Project' page:

  • 'Name' — the label for the project.
  • 'Template' — purely for your own administration. Pick the one that best describes it so it is easy to recognise later. It does not change or install anything.
  • 'Production UNIX User' — the UNIX user holding the live website or application.
  • 'Staging UNIX User' — the UNIX user holding the staging copy, if it lives in a separate UNIX user. Leave it unselected when there is no separate staging environment.

After importing, the project appears on the 'Projects' page and gets the project page described above.

When to use 'Advanced' instead

Core lets you create every underlying object by hand, under the top-level 'Advanced' menu.

The project is the website or application. The objects under 'Advanced' are the parts it is built from. Going to 'Advanced' first means assembling the same result yourself, and remembering which UNIX user, virtual host and FPM pool belong together.

Use 'Advanced' when you need to change one specific part, or when a setup does not fit the project model. Start with a project for everything else.

How projects are typically laid out

  • One project per client website, created with staging on, so the client has somewhere to approve changes before they go live. Because each environment runs under its own account, one client's site cannot read another's files.
  • Webshops — use the staging environment for theme and plugin updates, which is where storefront breakage usually comes from. Check the backups on production before every big change.
  • A project per environment, or per tenant when tenants get their own domain. The 'Advanced' tab is where you tune the FPM pool per tenant.
  • Existing sites — import rather than rebuild, so everything is visible in one place. Deploys still run over SSH against the environment's own login.