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 something that runs. Core builds everything it needs underneath: the UNIX user that owns the files, the virtual host that serves the domain, the PHP-FPM pool or Passenger app that runs the code, and a database where the template needs one. You don't create those one by one.

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.


Why start here

Core also lets you create every underlying object by hand, under the top-level 'Advanced' menu. You rarely need to.

Think of it this way. The project is the website or application. The objects under 'Advanced' are the parts it's built from. Creating a project builds and connects those parts for you, in the right order, with settings that match the template you picked. 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 doesn't fit the project model. Start with a project for everything else.

What a project contains

A project has:

  • 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. It can also have a staging environment, which is a second copy on its own domain for testing changes before they go live. See Staging environments and cloning.

Each environment has its own UNIX user, and therefore its own files, its own processes, and its own login. That's what keeps staging from touching production.

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.

From there:

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

Creating a project

The 'Create Project' page has three sections.

Project

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

Template

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

Template What Core sets up Installs the software?
'Static' Files served straight from disk, with 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, WordPress is installed for you
'Laravel' PHP, a queue worker, and a database with a user. No, bring your own Laravel code
'Craft' PHP, a queue worker, and a database with a user. No, bring your own Craft code

A tile is greyed out when the selected cluster doesn't support it. Hover it and the tooltip says what's missing, usually "Select a cluster with PHP support".

Depending on the tile you pick, extra fields appear:

  • 'PHP Version' for PHP, WordPress, Laravel and Craft.
  • 'NodeJS Version' for NodeJS.
  • 'Admin email' and 'WordPress version' for WordPress. The admin email is the address for the WordPress administrator account, used to recover the account and to receive WordPress notifications.
  • 'Use Blitz' for Craft. Blitz is a Craft caching plugin, and this toggle adds the nginx config that serves Blitz's cached pages directly, without starting PHP.

Staging Environment

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

You can only set this up while creating the project.

After you click 'Create Project'

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

The project page

Open a project and the left sidebar is organised around what you'd want to do.

When the project has a staging environment, a 'Production' and 'Staging' switch sits near the top of the sidebar. Most items below it show the environment you have selected, so you're always looking at one environment at a time.

Summary

Four panels covering the state of this environment:

  • 'Template': which template the project uses. For WordPress projects there's a 'Login' button that signs you into WordPress admin without you entering a password.
  • 'Language': the PHP or Node.js version this environment runs. 'Change' switches version, and 'Restart' restarts the pool or app.
  • 'SSL': how many of the project's domains have a certificate. 'View' opens a list of every domain and its certificate 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's UNIX user, and where you set or disable its password. See Change or disable a UNIX user's password.

Services

Per environment:

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

Logs

'Access' and 'Error' open the web server logs for the environment. Use the error log first when a request returns a 502 or a 500.

CMS

Shown for WordPress projects and for projects that have staging:

  • 'Search & Replace': replaces a string throughout the environment's database. The usual reason is 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': shown once the environment has a Borg repository. See All about backups.
  • 'Current Requests': the requests being handled right now. Useful when things are slow and you want to see what the site or application is busy with.
  • 'Malware': files the daily malware scan flagged for this environment. See Malware scanning.
  • 'Settings': 'Update document root' and 'Update PHP settings'.
  • 'Advanced': tiles for the underlying objects, each with a 'Manage' button. This is the bridge from the project to the UNIX user, virtual host, and FPM pool or Passenger app that the project is built from.

Craft

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

Importing what already exists

If a website or application already exists on the cluster as separate objects, 'Import' wraps a project around it instead of creating anything new.

On the 'Import Project' page:

  • 'Name': the label for the project.
  • 'Template': this is purely for your own administration. Pick the one that best describes it so it's easy to recognise later. It doesn't 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 if there's no separate staging environment.

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

Use cases by target group

How projects land per group

  • Web agencies: one project per client website. Create it with staging on, so the client has somewhere to approve changes before they go live. Because each environment has its own UNIX user, one client's site can't read another's files.
  • Shops: use the staging environment for theme and plugin updates, which is where storefront breakage usually comes from. Check the backups on the production environment before every big change.
  • SaaS: a project per environment, or per tenant when tenants get their own domain. The 'Advanced' tab is where you go to tune the FPM pool per tenant.
  • Tech agencies and large platforms: import existing sites rather than rebuilding them, so everything is visible in one place. Deploys still run over SSH against the environment's UNIX user.