Environmental and Sustainability Policy

Where we stand

SailCoach exists because of the weather. Wind, tide and temperature are the raw material of the sport we build for, and a sailor who trains for ten years is making a long bet that the water will still be worth sailing on. So we are not neutral about the climate, and we are not going to pretend that a small software company has no footprint.

We are also not going to claim more than we can prove. Innovology Ltd is a very small business. We do not hold any environmental certification, we have not had anything on this page audited, and we are not carbon neutral. What we can do is be precise about what we run, honest about how much electricity we think it draws, and clear about the difference between what we have measured and what we have modelled.

This page is written to the standard the Competition and Markets Authority sets in its Green Claims Code, and to the rules on misleading environmental claims in the Digital Markets, Competition and Consumers Act 2024. If a sentence here overstates our position, we want to know, and the last section on this page explains how to tell us.

What we run

Everything we operate runs as containers on one hosting provider, Railway. There are roughly thirteen of them:

• the website and the admin console you see in a browser;
• the main API, plus separate authentication, club and administration services;
• an API gateway that routes traffic to them;
• five background jobs — one that replays public race-tracking sites to capture GPS tracks, one that runs race analysis, one that pulls finished races from providers that publish them directly, one that reads published results documents, and one that goes looking for new regattas to follow;
• one older combined worker, left from before those jobs were separated, which still runs all of that work itself.

Alongside those, three managed pieces of infrastructure draw power and appear in no code we write: a MongoDB database, a Redis cache and job queue, and an S3-compatible object store holding race tracks, photos, video and documents.

Twelve of those thirteen containers are in the figure below. The thirteenth is not. The older combined worker has no size recorded anywhere in our repository and we have not estimated one, so it is listed as an exclusion rather than counted. It runs the race-capture job, which this page calls the most energy-intensive thing we do, so leaving it out understates the figure in our own favour. We are saying so here because a reader would otherwise reasonably assume that a container we have just described is inside the total. Sizing it is a commitment below.

Where they run

Our background job containers write the region they are running in into our own database every thirty seconds, so for those there is a live signal. Nothing else reports anything: the website, the API services, the gateway, the database, the cache and the object store tell us nothing about where they sit, and nothing in our configuration pins a region for any of them.

The two region names printed beside the figure below — EU West and US East — are not read from that signal. They are constants in our model, written by us from what we believe the deployment looks like. That is why every region row in the model is labelled assumed, and it is why the section on carbon further down hangs on an assumption rather than on a fact. Confirming the real answer is a commitment below.

Where personal data goes is a separate question from where electricity is drawn. It is dealt with in the Subprocessor List, which records the same locations as unconfirmed, and which is also the full list of who runs what and what data reaches them.

The live figure on this page

Below is a modelled estimate of the electricity our servers draw, and a running total from multiplying that rate by the time that has passed.

Be clear about which part of it moves. The rate does not. It is computed from the sizes we have allocated to each service, which are constants in our code, so it is the same number each time you load this page and it does not respond to how busy we are. The digits that tick are a clock, not a measurement. Nobody is measuring the current going into our containers.

What the rate is, exactly: how much processor and memory we have allocated to each service, multiplied by power figures taken from public research, multiplied by an industry-average factor for the data centre around them. The band shown next to the number is the honest range, and it is wide — roughly half to roughly double the central figure.

The counter starts from the date we deployed it. We have not back-cast it over earlier years, because our infrastructure changed shape in 2026 and any "total since 2024" would be a guess dressed as a record.

How the number is calculated

The model

For each service, for the database, the cache and the object store, we take:

power = (processors allocated × watts per processor, scaled by how busy it is) + (memory allocated × watts per gigabyte) + (stored terabytes × watts per terabyte)

We add those up across every service, multiply the total by a data-centre overhead factor (PUE — the ratio of total facility electricity to the electricity that reaches the computers, which covers cooling, lighting and power conversion losses), and that is the wattage shown. Energy is then simply that wattage multiplied by elapsed time, which is arithmetic your own browser does on this page rather than a number we store on a server.

Every coefficient in that formula is published on the page with its unit, its uncertainty range, its source and the date we last reviewed it. The processor and memory figures come from open cloud-carbon methodology work. The overhead factor is an industry-average data-centre figure, because Railway publishes no PUE for any of its facilities — so that term is an assumption about the industry, not a fact about our host, and it would still be an assumption even if we knew which building we were in.

Why it is an estimate and not a meter reading

This needs to be unambiguous, so here it is in plain terms.

We do not have an electricity meter at any boundary we control. There is no meter on our containers, no meter on our racks, and no rack that is ours. Railway does not expose per-container wattage, and we hold no instrumentation that measures power. Every figure on this page is a model output.

Three things follow from that:

1. We are modelling our allocation, not our consumption. We know how much processor and memory we have reserved. We do not know how much electricity the physical machine drew on our behalf, how many other customers shared that machine, or how much of the host's idle capacity should be attributed to us.
2. The uncertainty is large — about a factor of two. The coefficients themselves carry wide published ranges, and the overhead factor is an industry average rather than our host's actual number. A figure that can move by 2× is useful for direction and scale. It is not useful for comparing us against anybody else, and we would ask you not to use it that way.
3. Ticking digits imply a precision we do not have. We show the uncertainty band ticking alongside the central number for exactly that reason. If the band looks embarrassingly wide, that is the band being honest.

The inventory rows on the page are each labelled measured or assumed. Today every one of them says assumed, and so does every coefficient. Not one input to this figure has been measured, and none ever has been — the sizes of our containers are configured in our hosting provider's dashboard and are not recorded in code, and we hold no meter for anything else. We are not going to hide that behind a confident total, and two of the commitments below — the storage sweep and the live container count — exist to make at least part of it stop being true.

One thing on the page is genuinely observed rather than assumed: the count of background job containers reporting a heartbeat. It is shown as a cross-check on whether the model's picture of our deployment is still roughly right. It does not feed the figure. The model uses one replica per service whatever the live count says, so if we scaled the capture job to four the wattage above would not move.

What the figure does not include

This is not small print. The number above covers our servers and nothing else, and for a web product the excluded items are not marginal.

• The device you are reading this on. Your phone, tablet or laptop, and the electricity it is drawing to render this page. For a typical web service, end-user devices usually account for more total energy than the servers do. Excluding them is defensible — that is your electricity, not ours — but it means the figure above is emphatically not "SailCoach's footprint".
• The manufacture of any hardware. Servers, disks, network equipment, phones, laptops. Embodied carbon from manufacturing is a large share of a computer's lifetime impact and none of it appears here.
• Network transit. The energy used carrying data between our servers and you. We exclude it deliberately: the published energy-per-gigabyte coefficients for internet transit disagree with each other by an order of magnitude, and we would rather list network as an exclusion than publish a number with ten-fold uncertainty inside a total.
• Our own laptops and phones, and the electricity used to develop the product.
• Continuous-integration runners. Every time we push code, build and test machines run somewhere else. We deploy many times a day. That compute is real, it is not ours to meter, and it is not counted.
• Compute other companies run on our behalf. AI model inference at Anthropic, error monitoring at Sentry, email delivery at Resend, video serving at Cloudinary. None of them reports per-customer energy to us, and we are not going to model it from our own request counts — that would be our arithmetic dressed as their measurement. Language-model inference is the least intuitive of these and the one most likely to matter, so we name it first.
• Our older combined worker, as described at the top of this page. It is deployed, it draws power, and it is not in the total until we have sized it.
• Offices, travel, and everything that is not a server.

Where our electricity comes from

We buy compute, not electricity

We hold no electricity supply contract. We rent containers. The supply contract for the data centres our code runs in belongs to our hosting provider and, beneath them, to whoever operates the buildings. Any claim about renewable electricity is therefore somebody else's claim, which we are repeating — and under the Green Claims Code, repeating a claim does not make it ours to assert.

So we state it attributed and dated:

We have not independently verified either row. We have not visited a data centre, read a supply contract, or seen a certificate.

We are not claiming, and will not claim, that SailCoach runs on renewable electricity. Until we can cite a dated statement from our host covering the facilities we actually use, the honest position is that our servers draw whatever the local grid is delivering, wherever they are, at the moment you are reading this — and as set out at the top of this page, we have not confirmed where that is.

What a renewable tariff actually means

It is worth being clear about this, because "100% renewable" is one of the most misunderstood phrases in the industry.

Electrons are fungible. A data centre plugged into the grid draws the grid mix at every instant — whatever the wind, solar, nuclear and gas plants happen to be producing. No contract changes the physics.

What a renewable tariff means is that certificates equal to the electricity consumed have been bought and retired: REGOs in the UK, Guarantees of Origin in the EU, RECs in the US. Crucially, this is normally matched annually, not hour by hour. That is why a supplier can be "100% renewable" on paper across a year while the machines are physically running on gas-fired power at six o'clock on a still January evening.

There is a further criticism that regulators and consumer groups have made of unbundled certificates specifically: buying one does not necessarily cause any new renewable generation to be built. The wind farm was there anyway.

None of this makes renewable tariffs worthless. It does mean that "we run on 100% renewable energy" is a sentence about paperwork, not about electricity, and we are not going to write it. You will not find the words zero carbon, carbon neutral or green hosting anywhere on this page describing us.

Why we do not publish a single carbon figure

We publish kilowatt-hours and no gCO₂e, and that is deliberate.

Under the GHG Protocol, Scope 2 emissions must be reported two ways: a market-based figure, which reflects the contracts and certificates your supplier holds, and a location-based figure, which reflects the actual carbon intensity of the grid where the machines physically sit. They can differ enormously, and reporting only the flattering one is a well-known way to mislead.

A location-based figure needs a location, and we do not have a confirmed one. We believe we run in more than one region; grid carbon intensity between the regions our host plausibly uses varies several-fold; and multiplying an assumed region by an assumed allocation gives a carbon number whose two largest terms are both guesses. Collapsing that into one headline would hide the regional split, the market-versus-location distinction and the fact that we do not know where the machines are. A single carbon figure would be easier to read and less true, so for now we publish the energy figure — which we can defend — and not a carbon figure, which we cannot.

If we publish carbon later, it will be as both numbers, split by region, or not at all.

What we actually do to reduce impact

This list is short and specific on purpose. We are not going to inflate housekeeping into a strategy.

• We right-size services rather than running everything large. Our background work is split by role — capture, analysis, archiving, scheduling — precisely so that each can be sized and scaled for what it actually does. The race-capture workers are the only ones that need to run a browser; the archiving worker is cheap and mostly waits on input and is sized accordingly. The split is not finished: the older combined worker described at the top of this page still runs every role, which is the opposite of right-sizing and is why resolving it is on the list below.
• We capture each race once and reuse it. Capturing a race means replaying a public tracking site at real time in a headless browser — a 45-minute race costs 45 minutes of browser compute. Our processing is keyed to the race itself rather than to the event that links to it, and we check whether we already hold a race before capturing it. One regatta commonly appears under several event listings; we do not re-burn the compute for each one.
• We do not run video transcoding we do not need. Transcoding is the single most processor-hungry thing in the product. It runs one job at a time, produces a limited set of renditions, and is not run speculatively over material nobody has asked for.
• We delete data we no longer need. Storage draws power continuously, so keeping things forever has an energy cost as well as a privacy cost. Our Data Retention Schedule sets out what we keep and for how long — and is candid that most of that deletion is currently done by a person rather than by a scheduled job. Both facts are true, and the second one is a gap we are closing.

That is the list. Right-sizing, not duplicating expensive work, not transcoding speculatively, and deleting what we do not need. It is real, it is modest, and it is the honest total of what a company our size does.

What we will not do

We will not buy carbon offsets and call ourselves neutral.

We could. At our scale it would cost very little, and it would let us put a badge on this page tomorrow. We are not doing it, because a purchased offset does not change the electricity our containers drew, the quality and additionality of voluntary offsets are widely contested, and a neutrality claim we bought for a small sum would be the least honest sentence on our site. The Green Claims Code is explicit that offsetting-based neutrality claims need to be substantiated and explained rather than used as a headline, and we would rather not make the claim at all than make one we would have to defend with footnotes.

If we ever buy offsets, we will say what we bought, from whom, for how much, and we will still report our gross energy separately and unreduced.

Commitments, with dates

The reconciliation is the one that matters most. An estimate nobody can check is just a claim. Publishing "our model predicted X, we were billed the equivalent of Y, so our model runs N% low" turns this page from trust our number into here is our number's track record, and it is the only thing on this list that makes the figure falsifiable.

Travel, hardware and the office

We should say something about these, and what we say is short because we are small.

We have no office. Work happens from home, on domestic electricity supplies we do not meter separately and do not include in any figure here. Our hardware is a handful of laptops and phones, kept until they stop working rather than replaced on a cycle. Since manufacturing dominates a computer's lifetime impact, keeping them longer is the most useful thing we do about hardware, and it is not much. What happens further up that supply chain, in manufacturing and in data-centre construction, is covered in our Modern Slavery and Ethical Supply Statement.

Travel is to sailing clubs, training sessions and regattas, mostly by road and mostly in the UK. We have not measured it and we do not publish a figure for it. We are not going to describe it as negligible on the basis that we never counted it.

Challenging anything on this page

If you think a number here is wrong, a coefficient is out of date, a source does not say what we claim it says, or a sentence reads as a greener claim than the evidence supports, write to [email protected]. Tell us which sentence and why. We will reply within five working days, and if you are right we will correct the page and say in the version history what changed and why.

That includes the model itself. The formula, the coefficients and their sources are published on this page rather than kept internally, precisely so that a reader who knows more about data-centre energy than we do can tell us where we have got it wrong.

Innovology Ltd, trading as SailCoach, is registered in England and Wales.