Update application and database port configurations

Adjusted Docker configuration, exposing PostgreSQL on port 4523 and the application on internal port 5555, with Nginx proxying requests to the application. Updated Dockerfile, docker-compose.yml, and DOCKER.md accordingly.

Replit-Commit-Author: Agent
Replit-Commit-Session-Id: ae4037a0-2a6f-4530-9bac-79b543286bda
Replit-Commit-Checkpoint-Type: full_checkpoint
Replit-Commit-Screenshot-Url: https://storage.googleapis.com/screenshot-production-us-central1/397bca8c-984f-43ff-841a-10897aeb8140/ae4037a0-2a6f-4530-9bac-79b543286bda/rBcOjHB
This commit is contained in:
michaelschal committed 2025-10-17 13:09:32 +00:00
1 parent 5bd45764b4
commit 8ea8ad8085
5 files changed
+19 -19

No files matched your search

+1 -1
View File
@@ -11,7 +11,7 @@ Preferred communication style: Simple, everyday language.
## Recent Changes
### October 17, 2025
- **Docker Deployment Configuration**: Configured Docker Compose for private server deployment with PostgreSQL and application on same network. Application exposed on port 4523:4523 as requested. PostgreSQL and app communicate via internal Docker network and are both on nginx_default external network for reverse proxy access. Updated Dockerfile to use port 4523. Created comprehensive DOCKER.md documentation with setup instructions, network architecture explanation, and troubleshooting guide.
- **Docker Deployment Configuration**: Configured Docker Compose for private server deployment with PostgreSQL and application on same network. PostgreSQL exposed on port 4523:5432 for external access. Application runs on internal port 5555 (accessible via Nginx reverse proxy). Both PostgreSQL and app are on nginx_default external network and internal network for communication. Created comprehensive DOCKER.md documentation with setup instructions, network architecture explanation, and troubleshooting guide.
### October 14, 2025
- **Publication History Error Display Fix**: Fixed bug where publication history incorrectly displayed persistent errors for posts that failed initially but succeeded on retry. Problem: When a post failed, the `error` field was populated, but when the post was successfully republished, only `publishedAt` and `externalPostId` were updated without clearing the `error` field. Solution: Modified `schedulerService.publishPost()` to set `error: null` when publication succeeds, ensuring error messages are cleared from the history view after successful republication.