CNC Production Board
| Machine Name |
Part Description |
Cycle Time (seconds) |
Eff % | Target | Thursday |
Friday |
Weekend |
Monday |
Tuesday |
Wednesday |
|||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 12HR | 24HR | Thursday Day Shift |
Thursday Night Shift |
Friday Day Shift |
Friday Night Shift |
Saturday | Sunday | Monday Day Shift |
Monday Night Shift |
Tuesday Day Shift |
Tuesday Night Shift |
Wednesday Day Shift |
Wednesday Night Shift |
||||||
This will archive the current week and clear all daily output cells ready for a new week.
This action cannot be undone. Please ensure all data has been entered before proceeding.
⚠ This week isn't over yet — today's date still falls within it.
Archiving now will move the board on to next week. Only continue if you really mean to.
Brings back the week you most recently archived — its data returns too, ready to keep editing. It also undoes a week you over-stepped into. If you over-stepped but that week's archive was deleted, only the dates move back. Otherwise the button greys out, so it can't be used to wander back through ordinary past weeks.
Drag the handle to move a row. Each machine carries its data with it. Nothing changes on the board until you press OK.
This action cannot be undone.
This action is permanent and cannot be undone.
The board has no data entered this week.
Please enter some data before archiving.
This will permanently delete this message for all admins.
Only delete once the message has been acted on.
Passwords are never stored in plain text. Each password is protected using PBKDF2-SHA256 encryption with a unique random salt and 200,000 iterations — the same standard recommended by OWASP (the global authority on application security) for password storage. Even if the underlying data were accessed directly, passwords could not be recovered from it.
Board data is stored on Supabase, a secure cloud platform utilising AES-256 encryption and TLS/HTTPS encrypted connections on all data transfers, ensuring data is protected both at rest and in transit.
The board itself is hosted on Netlify, a platform built for secure, reliable delivery of web content. Every connection is encrypted using HTTPS/TLS, and the page is served from Netlify’s global network for fast, consistent loading wherever it’s opened. Netlify and Supabase are complementary by design — Netlify secures delivery of the application itself, while Supabase secures the data behind it, together covering the full path from the page loading in a browser to the data it reads and writes.
Independent third-party protection. Security does not rely on the board application alone. All data is held and encrypted by Supabase using AES-256 — the same encryption standard used in banking — and every connection is independently encrypted by the hosting and database platforms. Passwords are never stored or transmitted in readable form at any point. In addition, access rules enforced at the database level restrict what operations can be performed on the data and prohibit deletion entirely, independently of anything running in the browser. Protection of the data is therefore enforced by established, independently audited cloud platforms, not just by the application itself.
Auto-lock ensures that unattended screens require re-authentication after a configurable period, protecting against unauthorised physical access.
After five incorrect login attempts the form locks, and each further burst of failed attempts locks it for progressively longer (from one minute up to several hours), making sustained password guessing impractical while barely inconveniencing a genuine mistyped entry. A successful login resets this straight away, so an occasional mistake never carries over.
Second authentication layer. Access can require a personal PIN in addition to the shared password. Both are entered together, and a failed attempt reports only that login failed — never which of the two was wrong — so neither can be probed on its own. Each person’s PIN is issued individually and can be revoked at any time, allowing one person’s access to be withdrawn immediately without affecting anyone else or forcing a password change across the workforce. PINs receive the same protection as the passwords: each is stored only as a one-way PBKDF2-SHA256 hash (200,000 iterations, salted) inside the same AES-256 encrypted database, and is never held or transmitted in readable text — so, exactly like the passwords, a PIN cannot be recovered from the stored data by anyone.
No record of logins is kept. The board does not log who signs in, or when: no names, no PINs and no login times are recorded by the application. At login the system checks only that a valid, active PIN was entered — it does not record, and has no means to report, which individual it belonged to. No monitoring or profiling of staff activity is performed.
Minimal personal data. The only staff information held is a list of names, each paired with a hashed PIN. This is an access list, not an activity record: it is held solely to control who may view the board’s commercially sensitive production information — output, schedules and customer work — and to allow that access to be removed promptly when an individual leaves ATC Ltd. On leaving, a person’s entry is deactivated immediately and cleared in routine housekeeping, so it is kept no longer than needed for that purpose. The names are not written into the program file itself; they are held in the encrypted database (AES-256 at rest, TLS in transit), not in any form that can be read from the page.
Passwords should never be shared outside the organisation. All users are expected to keep credentials confidential and must not disclose them to any third party external to the company. Unauthorised sharing of access credentials should be treated as a breach of company policy.
Authorised changes only. This application, its source code, its hosting, and its stored data are the property of ATC Ltd. Only ATC Ltd and the original developer are authorised to modify the application, deploy changes to it, or alter its data other than through normal authorised use. No other person may deploy, publish, or otherwise change the live system or its database, whether directly or through any copy of the program. Unauthorised modification of the system or its data may be treated as a disciplinary matter.
Here’s what all the security terminology on the previous page actually means, without the jargon.
🔑 Your passwords are never actually stored anywhere
When a password is set, the system doesn’t keep the password itself — it keeps a scrambled “fingerprint” of it. When someone logs in, their entry is scrambled the same way and the fingerprints are compared. The scrambling is strictly one-way: you can make the fingerprint from the password, but nobody — not even the people who run the storage — can turn the fingerprint back into the password. So there is no list of passwords anywhere that could be stolen.
✉️ Everything travels in sealed envelopes, not postcards
Whenever the board loads or saves anything, the information is encrypted while it travels across the internet — like sending a sealed, tamper-proof envelope instead of a postcard anyone could read along the way. Anyone intercepting the traffic would see only meaningless scrambled data. This is the padlock symbol you see in the browser’s address bar.
🏦 The stored data sits in the equivalent of a bank vault
The board’s data is stored in encrypted form using the same grade of encryption that banks use for financial records. Even in the extremely unlikely event someone physically got at the storage, what they’d find would be unreadable without the encryption keys, which are managed separately.
🏢 Two specialist companies, each doing what they do best
The board is looked after by two established cloud companies with complementary jobs. Netlify delivers the board itself to the screen — like a courier that guarantees the page arrives intact, quickly, and over a secure connection. Supabase guards the data behind it — the filing cabinet where everything the board displays is kept. Both are professionally run, independently audited platforms used by thousands of businesses; this isn’t a server sitting under someone’s desk.
🗄️ The filing cabinet has its own rules that nothing can override
The database itself enforces strict rules about what the board’s connection is allowed to do: it may read and update the board’s own records, and nothing else. It cannot touch anything outside the board’s own drawer, and it cannot delete anything at all — the ability simply doesn’t exist. These rules are enforced by the database company’s systems, completely outside the board itself, so they hold firm no matter what happens in anyone’s browser.
🚪 Guessing passwords gets you locked out
Five wrong attempts and the login locks — and each further run of wrong attempts locks it for longer, from about a minute up to a few hours, with a visible countdown. That turns guessing from a quick exercise into a hopeless one. A correct login clears it straight away, so the odd genuine slip never counts against you.
🔢 Each person can have their own PIN
As well as the shared password, each person can be given their own personal PIN, typed in alongside it. The two are checked together, and if either is wrong the board just says “login failed” — it never tells you which part was wrong, so neither can be worked out on its own. The real advantage is what it lets us do when someone leaves: their PIN is switched off and they can no longer get in, immediately, without changing anything for anyone else. PINs are protected in exactly the same strong, scrambled way as the passwords — stored so that no one can read them back, not even us.
🙈 The board keeps no record of who logs in
The board doesn’t note who signs in, or when — no names, no PINs and no sign-in times are kept. When someone types their PIN, the board only checks that it’s a valid, current one; it has no way of knowing, or reporting, whose it was. The only staff information kept anywhere is a simple list of names each paired with a scrambled version of their PIN — and that’s purely to decide who’s allowed in and to switch off access when someone leaves. It’s never used to keep an eye on what anyone does. And to be clear about where those names live: they’re not sitting in the program file for anyone to read — they’re kept in the locked, encrypted database, the same vault as everything else, not in the page itself.
🕵️ The board doesn’t show up in searches
The board’s web address is deliberately kept out of Google and other search engines. The only people who know where it lives are the people we’ve told. And even someone who did have the address would still be standing in front of the password screen.
💤 Unattended screens lock themselves
If auto-lock is switched on, a screen left alone re-locks itself after a set time and asks for the password again — so a logged-in board isn’t left open indefinitely for anyone passing by.
🧍 The honest bit: the biggest risk is people, not technology
All of the above means the technical side is handled by professional platforms doing this at industrial scale. The one thing no technology can protect against is a password being given away. Keep passwords inside the company, and the rest of the system does its job.
Please remember
This board belongs to ATC. Please do not share or distribute the program file to anyone. Do not attempt to edit or change the program file in any way. And never reveal any of the passwords to anyone outside the company.
| Section | Front Board | Back Board | ||
|---|---|---|---|---|
| Admin | User | Admin | User | |
Who can send messages?
Anyone logged in — users and admins alike — can send a message. This is the primary way shop floor users communicate with the admin team, for example flagging a problem with a machine or requesting something.
Who can read messages?
Only admins can read incoming messages. Users cannot see the message inbox.
How do I know a new message has arrived?
A coloured badge appears next to the blue envelope icon in the top bar. The colour reflects the priority the sender chose (the labels shown here are exactly what the sender picks on the compose screen):
What do the badge states mean?
Reading is tracked per device
Read state is stored on each device (in that browser), not against a login. So if a message is read on one screen it dims there, but it'll still show as unread on a different screen until it's read there too. Two admins each on their own device track their reads independently — but if they share the same screen, they share the same read state.
Deleting a message
Deletion removes the message from the system for all admins permanently. Only delete a message once it has been fully acted on. The confirmation dialog will remind you of this before you proceed.
The golden rule
Read = you've seen it. Delete = it's done. Don't delete someone else's unread message.
The front board is the main CNC production grid. Each row is a machine, and each column pair represents the two 12-hour shifts in a day — a day shift and a night shift — across a full working week. Click any data cell to open the Edit Cell panel and enter or change its content.
The back board is the flip side of the production board, made up of panels you can fill with formatted notes, tables, images and more. Everyday users see it as view-only — editing is for admins. Changes save when you close a panel, not as you type, so finish your edits then close.
Once on the back, the bottom bar shows two buttons either side of Flip Board — a left and a right slide button, each labelled with the board it opens (for example ← Left Panels and Right Panels →). Click one and the board slides across to its neighbour at the same pace as a flip. Both buttons always work, on every board: the five form a loop, so pressing past Far Right brings you round to Far Left and vice versa — you can keep going in one direction for as long as you like. Pressing the same button again while a slide is still running redirects it on the move rather than waiting, so a quick double-press travels two boards in one smooth run. Five presses is the most it will take at once, which is a full lap back to where you started. Flip Board returns you to the front from anywhere.
Each one is explained below, in that same order.
The Settings panel slides in from the left. What you see inside it depends on two things: your role (admin or ordinary user) and which side of the board is currently showing (front or back). Because of that, two people opening Settings can see different options. Every section below is tagged to show who can see it and on which board it appears.
The Security panel is the single place to manage how the board is protected. It contains three areas:
Auto Lock — choose how long the board can sit idle before it requires the password to be entered again. Options range from 5 minutes up to 24 hours, or Never. The screensaver and carousel continue to run as normal display modes; the login prompt only reappears the next time someone actually interacts with the board after the chosen period has passed. This protects against an unattended screen being accessed by someone walking up to it. The setting is shared, so it applies to every PC running the board.
Change Passwords — for added protection, the admin password must be re-entered before any password can be changed, even when already logged in. Once confirmed, the User and Admin passwords can each be updated. This “confirm before changing” step is the same approach used by online banking and is designed to stop anyone altering access on a screen that has been left logged in.
Data Security statement — a plain-English summary of the protections in place, suitable for sharing with management or an external IT provider.
Password protection. Access to the board is controlled by separate User and Admin passwords. Passwords are never stored in plain text anywhere. Each one is protected using PBKDF2-SHA256, an industry-standard one-way encryption method, combined with a unique random “salt” and 200,000 hashing iterations — the level recommended by OWASP, the global authority on application security. Because the process is one-way, the original passwords cannot be recovered from the stored data by anyone, including the developer.
Re-authentication. Changing any password requires the admin password to be entered again at the point of change, preventing unauthorised changes on an unattended logged-in screen.
Auto lock. The board automatically requires re-authentication after a configurable period of inactivity, protecting against unauthorised physical access to an idle screen.
Data storage & transmission. Board data is held on Supabase, a secure managed cloud platform. Data is encrypted at rest using AES-256 and in transit using TLS/HTTPS encrypted connections, so information is protected both where it is stored and as it travels between the board and the server. Access is governed by Row-Level Security policies enforced by the database itself: the access credential used by the board is restricted to reading and updating the board’s own data only, and is prohibited from deleting data entirely — restrictions that apply regardless of anything running in the browser.
Independent third-party protection. Security does not rely on the board application alone. Data encryption, encrypted connections, and the database-level access rules described above are all enforced by established, independently audited cloud platforms (Supabase and Netlify), outside and independent of the application. Passwords are never stored or transmitted in readable form at any point.
Hosting & delivery. The board is hosted on Netlify, a platform purpose-built for delivering web content securely and reliably. Every connection to the board is encrypted using HTTPS/TLS, and the page is served from Netlify’s global content delivery network for fast, consistent loading wherever it’s opened. Netlify and Supabase are complementary by design: Netlify looks after securely delivering the application itself, while Supabase looks after securely storing and serving the data behind it — together covering the full path from the page loading in a browser to the data it reads and writes.
Access control. The board is reachable at a web address rather than only on company PCs, which is what allows an update to reach every screen at once without reinstalling files. That address is not published or indexed by search engines, and every visitor — regardless of how they reached the page — must pass the password check described above before any board data is shown. After five incorrect attempts the login locks, and repeated failed bursts lock it for progressively longer, deterring password guessing. Once someone logs in successfully this resets, so the odd mistake is never held against you.
Access can also require a personal PIN alongside the password. Each person’s PIN is their own and can be switched off at any time, so if someone leaves the company their access can be stopped straight away without changing anything for everyone else.
The board keeps no record of who logs in or when — no names, no PINs and no sign-in times are stored. When someone enters their PIN the board only checks that it is valid and current; it doesn’t note whose it was. The only staff information kept at all is a simple list of names, each with a scrambled version of their PIN, held purely to decide who is allowed in and to switch off access when someone leaves. It is never used to track what anyone does.
User responsibility. As with any password-protected system, security ultimately depends on the people who hold the passwords. Passwords should never be shared outside the organisation or disclosed to any third party. Unauthorised sharing of access credentials should be treated as a breach of company policy.
Authorised changes only. This application, its source code, its hosting, and its stored data are the property of ATC Ltd. Only ATC Ltd and the original developer are authorised to modify the application, deploy changes to it, or alter its data other than through normal authorised use. No other person may deploy, publish, or otherwise change the live system or its database, whether directly or through any copy of the program. Unauthorised modification of the system or its data may be treated as a disciplinary matter.