rPman

100р в месяц это не обслуживаемые vps, т.е. настраивать и администрировать самому, с не высокими SLA (примерно раз в несколько месяцев будут останавливаться, часто без уведомления заранее, по техническим причинам хостера), например поисковик по таким lowendstock.com (там даже с оплатой в криптовалюте).

С таким подходом, начинать лучше вообще с домашней машины, некоторые роутеры (не самые дешевые, например с поддержкой OpenWRT, но тут еще вопрос про требования к серверу, а точнее оперативной памяти) или лучше любой дешевый компьютер (мне нравятся решения на базе mitx soc плат с ценами порядка 13-15т.р. например на базе intel celeron n или j серий, они в несколько раз лучше малинки а больше всего в 2-3 раза, их обычно напаивают на материнскую плату и решения с ними можно сделать до 10т.р. и там на цену больше может повлиять способ питания и корпус а не сама электроника, в россии такие уже не поставляются но вот первый же интересный из доступных пример ему блок питания и память добавить любые, потребление у него 15ватт) а экстремалы могут даже на android устройствах запустить (любой БУ смартфон).

Осторожно с медицинской тематикой, в россии (да во всех странах) это регулируемая область, просто так хостить приватные данные нельзя и поэтому за 5 копеек легально не получится.

С самой задаче не сюда, тут посоветуют в каком направлении решать задачу самому. Принять решение о стоимости не получится, не видя задачу. Но первый вопрос, почему нужно именно сайт?

p.s. в некоторых случаях могут подойти решения на базе облачных услуг каких-нибудь гугл диск но это извращение, хостить может будет бесплатно/дешево но разрабатывать и поддерживать сложнее

Да в некоторых случаях возможно защититься от создания фейковых видео.
Контент на записываемом сайте должен быть невоспроизводим заранее и это можно было бы проверить.

Для этого все изображение должно быть обработано, в ключевые для задачи места (которые нужно защитить от подделки) необходимо добавить модификации, в которых закодирована цифровая подпись. Что бы это было слабо заметно человеку, это могут быть слабые изменения в цвете пикселов или их сдвиги с помощью стеганографии, сообщаешь всем заинтересованным об алгоритме извлечения значения, и сохраняешь в нем цифровую подпись данных.

Т.е. в твоем случае Сайт 1 и Сайт 2 должны на своих страницах в ключевых местах оставлять такую цифровую подпись на изображении и предоставить механизмы проверки видео на наличие в них подписи (т.е. нужно будет покадрово анализировать изображения и сообщать что вот в этом кадре вот в этой области есть информация и она подписана)

Так же в этой информации должна быть заложена информация о текущем времени (что бы нельзя было подсунуть старые изображения).

Так же лучше подписывать не все изображение целиком, а разделить его на области (например прямоугольная сетка) и подписывать каждую по отдельности, тогда метод записи будет не так критичен (например человек может записывать внешней камерой, трясущимися руками)

Все скрывается за

нужен приятный интерфейс

потому что обычные html формы пишутся буквально чем они являются, и ничего другого не требуется

<form action="doit.php">
<input name="xxx" value="yyy"/>
<input type="submit"/>
</form>

Большая часть работы разработчика - это рюшечки, безопасность и поддержка кода в команде и во времени

https://threejs.org/
например на его основе написан просмотрщик на thingeverse

Общие положения обеспечения безопасности - все сервисы, не используемые из интернета (но лучше все, кроме специализированных типа vpn или ssh, а доступ к остальным реализовать через них) должны быть закрыты фаерволом или настройками самого устройства...

Из вопроса совсем непонятно, что это за cgi сервис. cgi это простая и популярная (используется до сих пор) технология реализации backend веб сервера в интернете, сама по себе не содержит уязвимостей (точнее уязвимостью будет неправильная настройка), но вот те приложения, которые обслуживают ответы веб сервера (у тебя это cgi-aplication.exe и кстати название в ссылке не обязательно совпадает с тем что используется) могут и будут содержать ошибки... мало того, если кто то умудрился реализовать cgi веб приложение на windows на основе cgi и .exe, с огромными шансами эти ошибки допустит, 'никто' в здравом уме так не делает.

В общем ответ - если есть возможность, то 'не светить'

Я знаю, очень часто у компании нет нескольких миллионов рублей, что бы заплатить сторонней компании на атусорсе, что бы реализовать свои хотелки, к тому же, выбрав компанию разработчика, вы подсядете на его вендорлок (искусственно созданные усложнения, затрудняющие поддержку другими разработчиками) и сменить уже почти не получится, а зная это, компания будет требовать даже за простую работу высокую стоимость и дальше.

Правильный подход, любой компании, где работает от порядка 100 человек, выращивать внутри свой отдел по разработке и поддержке своего внутреннего ПО. К сожалению очень сложно убедить руководство компании нанимать для этого готовых специалистов, которые, временами (по нескольку месяцев), не будут иметь работы в принципе и в лучшем случае будет нанят один или несколько человек, совмещающие должности, да еще и без значительного опыта. Именно поэтому я сказал выращивать - выбирать желающих среди своих сотрудников с малым опытом но не совсем новичков конечно, пусть совмещают.

Готовое решение никогда не будет полностью готовым! Всегда в нем будет требоваться что то доработать под нужды организации. Именно на этом (и не только) зарабатывают 1С разработчики, коробочная версия продукта, с хорошей поддержкой законодательства и возможностью доработки... только уж дорого получается.

p.s. задачу нужно начинать с проведения анализа, составления ТЗ (даже если кажется что это простенькая задача),.. и где то в самом низу можно подумать о выборе технологих и фреймворков, уже после того как уже есть люди, которые будут готовы это решать и в них разбираются

Если все же хотите ответ на вопрос - выбирайте веб технологии. Работа на клиентских устройствах в браузере решит проблемы совместимости с железом. Если выберите устаревшую но не потерявшую актуальность технологию генерации html на бакэнде, то требования к клиентскому железу будут еще и самые низкие (на самом деле можно писать на javascript интерфейсы для браузера правильно, эффективно и не сильно сложно, но выросло огромное количество специалистов, замусоривших рынок катастрофическим оверинженерингом, и мне кажется уже и не помнят что можно просто делать все).

Задача в вашей постановке не выглядит сложной, если убрать дизайн и рюшечки, решается опытным разработчиком за пару-тройку вечеров.. но наверняка есть невысказанного много

Непрерывно! но не тестирование а мониторинг уже имеющейся нагрузки.

Сравнение нагрузочных метрик из операционной системы (нагрузка на процессор, память, диск и сеть) с количественными характеристиками - количество пользователей, их активность (включая вне сайта, например оплата), запросы к веб серверу, количество отказов и ошибок.

Читал что поверх собранной статистики (чем подробнее тем лучше) собирают небольшую нейронку, выявляющую нетипичные паттерны, это помогает заранее выявить даже атаки (тот же ддос и автоматизации), прогнозировать будущую нагрузку и оперативно аапгрейдить железо/добавлять нод в кластер.

p.s. как только ты выходишь на некоторый порог количества пользователей, то каждый твой апдейт (даже если тебе кажется что это ничего важного не затрагивает) должен проходить полное тестирование в специальной песочнице (именно поэтому нужна автоматизация, но и ручное не забывают), и в качестве одного из шагов, тяжелый функционал тестируют синтетической нагрузкой, создаваемой на основе мониторинга реальной.

Логи нужно не просто писать в какую-то базу, а делать их машиночитаемыми, иначе смысла нет.

Пишут тут что это нужно только если у тебя миллионы запросов и гигабайты логов.. все это чушь (не совсем, просто если у тебя маленький проект, пользу логи будут приносить редко), а вот централизованная работа с логами со всех своих инстансев и даже проектов, очень даже неплохо, облегчает мониторинг, облегчает разработку, облегчает поиск проблемных пользователей/ситуаций и т.п... но ценою ресурсов на это.

А так, первым шагом можно вместо записи в базу данных, просто писать в jsonl (построчно по json на событие), по меньше упаковки в человекочитаемые строки и побольше читаемые машиной, постаравшийсь полностью исключить вывод сообщений об ошибках в stdout/stderr, и над именованием файлов подумать, что бы удобнее с ними было работать.

ТЗ дано, в целях - простое, про авторизацию не заикнулись...

Реализация будет состоять из 3 частей:
1. интерфейс - frontend
2. серверная часть backend
3. из-за особенности реализации backend большинством инструментов и веб серверов, регулярные операции делают сторонним скриптом, обычно его запускают средствами ОС (его шедулером), в linux это cron

Итак, интерфейс из одного окна - окно запроса текста с кнопкой отправки с сообщением о результате, на основе html forms:
Бакэнд на php это эта же самая страница, но в местах где нужно менять содержимое по логике (где нужно вывести сообщение о результате) ставится <?php ... код ... ?>. Вот пример сохранения введенного сообщения пользователем в файл, имя которого будет содержать номер сессии пользователя и время (timestamp, это сделано намеренно что бы показать проблему именования файла в данной задаче при многопользовательском доступе, если использовать просто timestamp, т.е. время в секундах, то несколько одновременно посланных сообщений заменят друг друга и останется только последнее, в приведенном примере эта проблема сохранится только для одного 'пользователя' т.е. сессии браузера - открытой страницы что даже локально сложно добиться, естественно правильно делать индекс со списком файлов но зачем, задача то простая):

И соответственно скрипт удаления старых сообщений

Само собой права доступа на каталог должны быть выставлены корректно, никаких ошибок не логируется.

Никаких лимитов, никакой авторизации и защиты от ддос... в данном примере любой пользователь может забить содержимое диска на сервере, отсылая бессмысленно гиганские запросы с пустым текстом (пробелы например, они буду эффективно сжаты браузером)

Начни с простого чата, есть готовые примеры на основе websocket (на javascript там очень просто), идеологически это именно то что тебе нужно, потому что мультиплеерная игра это буквально чат между фронтэндами и бакэндом в обе стороны.

Не смотри на фреймворки, ПОКА они тебе только помешают, тебе нужно понять принцип.

Вопрос слишком всеобъемлющий, разбей задачу на подзадачи и спрашивай то что не понимаешь.

в консоли разработчика -> сеть -> нужный запрос, правая кнопка мыши, копировать как curl

Получишь команду вызова консольного curl, полностью повторяющее запрос (очень редко когда детектируют, через особенности ssl, были тут вопросы про это)

Но нужно понимать, что если разработчик сайта хочет запретить автоматизацию, он может потребовать к каждому запросу прикреплять особые значения полей, которые каким-то образом вычисляются на javascript, поэтому их тоже придется анализировать и симулировать

Изображения и тексты это легко, у них 'простой' формат и реализовать все в браузере будет не сложно, а вот для предпросмотра документов word нужен собственно этот word, так как у него сложный формат (еще сложнее был бы excel).

p.s. pdf

Если прямо очень нужно, подними на сервере какой-нибудь совместимый headless инструмент (например libre office, у него наилучшая совместимость с майкрософтовским) и используй его для конвертации документа во что то читаемое в браузере - напрямую изображения или pdf (через печать документа в виртуальный принтер), и то и другое уже не проблема отобразить.

с примерами, максимально просто: https://www.w3schools.com/html/html5_audio.asp

p.s. платформы типа vk запрещают (в т.ч. техническими средствами) использование 'своих' мультимедиа данных на чужих платформах, что логично, с какой такой стати они должны тратить деньги на хранение и раздачу мультимедиа бесплатно?

поэтому сами файлы размещай на своем сервере или каким либо другим способом, подразумевающим это

Список юзеров получаем с бэкенда. Для этого нужно установить и запустить локально сервер.

т.е. у тебя УЖЕ есть сервер и тебе его просто запустить, открываешь документацию по этому серверу и работаешь (ее должны были написать те кто делал этот сервер), либо, если документации нет, изучаешь весь код

в документации по nodejs приведет сразу же пример простейшего веб сервера, ищи что то похожэее, смотри в каких файлах идет вызов и соответственно запускай этот код

p.s. есть практика размещать все необходимое для запуска приложения в настройках пакета, тогда запуск будет что то типа:

npm install
npm build
npm run-script start

Т.е. install установит и обновит зависимости проекта, build запустит скрипты подготовки и оптимизации (например webpack), в общем что указано разработчиками, ну и запуск run-script start

И конечно, если это сделать в каталоге проекта в терминале, то закрытие терминала все закроет автоматически, поэтому это нужно будет прописать в виде сервиса systemd или каким то другим способом, принятом в твоей ОС

Куки - это механизм сохранения 'состояния' веб приложения, привязанное к пользователю, между сессиями его (приложения) использования.

Для собственно авторизации куки не обязательны, ведь это состояние можно передавать и через GET/POST запрос или #anchor ссылки или просто настройка кастомных заголовков (работает только для ajax запросов но не для обычных). Другой вопрос в том, что пользователи привыкли, что сайты сохраняют какое то время авторизацию и не требуют ввода логина и пароля уже для следующего посещения.