Default ports for website projects

Each of our website projects is configured to run on a different port by default.
This port should be defined in a .env file within the project codebase, and
should be between 8001 and 8999, excluding more commonly used ports like 8008.

This is so that team members can easily run multiple projects at the same time without getting port conflicts.

Defaults

Port Project
8001 www.ubuntu.com
8002 www.canonical.com
8003 partners.ubuntu.com
8004 snapcraft.io
8005 conjure-up.io
8006 maas.io
8007 docs.ubuntu.com
8008 RESERVED: Alternative HTTP port
8009 cloud-init.io
8010 cn.ubuntu.com
8011 design.ubuntu.com
8012 jp.ubuntu.com
8013 tour.ubuntu.com
8014 vanillaframework.io
8015 developer.ubuntu.com
8016 tutorials.ubuntu.com
8017 assets.ubuntu.com
8018 manager.assets.ubuntu.com
8019 community.ubuntu.com
8020 usn.ubuntu.com
8021 RESERVED: Possible use by iTunes Radio streams
8022 usn.ubuntu.com
8023 insights.ubuntu.com
8024 netplan.io
8025 360
8026 multipass.io
8027 microk8s.io
8028 mir-server.io
8029 jaas.ai
8030 docs.snapcraft.io
8031 landscape.canonical.com
8032 juju-gui
8033 docs.jujucharms.com
8034 certification.ubuntu.com
8035 kubeflow-news.com
8036 jaas-dashboard
8037 dqlite.io
8038 etclite.io
8039 microstack.io
8040 charmed-kubernetes.io
8041 juju.is
8042 charmed-osm.com
8043 anbox-cloud.io
8044 ideahub
8045 charmhub.io
8046 charmed-kubeflow.io
8047 pythonoperatorframework.io
8048 summit.ubuntu.com
8049 microcloud.is
8050 forms.canonical.com
8051 library.canonical.com
8066 feedourfrontline.org
8099 demoservice
8101 vanilla-framework
8102 vanilla-framework-react
8104 specs.canonical.com
8201 phone-docs
8202 snappy-docs
8203 maas-docs
8204 conjure-up-docs
8205 juju-docs
8206 security-certs-docs
8207 ubuntu-core-docs
8300 global-nav
8301 cookie-policy
8302 dynamic-forms
8400, 8401, 8402, 8404 maas-ui
8403 react-components
8405 maas-site-manager
8406 anbox-cloud-dashboard
8407 lxd-ui
8409 masterclasses
8410 ReBAC Admin
8411 identity-platform-admin-ui
8412 ReBAC Admin mock API

Why use a fixed port

We could have chosen to solve the problem of port clashes by having the local development
tooling choose a random open port, instead of defining a specific one.

There are a few benefits to the local development application having a predictable port:

  • Port clashes will remind developers that a specific project is already running locally
  • Developers can reliably bookmark their locally running version of specific projects, and so quickly check if a project is currently running
  • The port can reliably be mentioned in READMEs and pull request instructions
  • Any inter-linking dependent services can work together more easily if they know which local ports to connect to

However, it should be possible to choose to run any project on a different port through the standard dotrun tooling:

dotrun serve --port 8999

Last updated a month ago.