DEV Community: Beny

Monitoring Reset Request Logs: A Simple Step Toward Better Server Security

Beny — Wed, 26 Aug 2026 09:21:51 +0000

Today, I worked on understanding how to monitor reset request logs and why tracking these requests is important for server and application security.

Reset requests can include actions such as:

Password reset requests
Account recovery requests
Authentication-related reset requests

While these features are useful for users, they can also become a target for abuse.

What Are Reset Request Logs?

Whenever a user sends a reset request, the application or server can record useful information about the request.

A log entry may contain details such as

Timestamp
Request Type
User/Account Identifier
IP Address
Request Status
Response Status

These logs help developers understand what is happening on the server.

What Should We Monitor?

Instead of looking at individual requests manually, we can look for patterns.

For example:

Normal:
1 reset request → user → successful response

Suspicious:
20 reset requests → same IP → within a few minutes

A sudden increase in reset requests from the same IP or for the same account could indicate automated requests or abuse.

Why Monitoring Matters

Monitoring reset requests can help identify:

Repeated reset attempts
Unusual request patterns
Automated/bot activity
Possible account abuse
Unexpected server traffic
Failed requests
Authentication-related issues

The goal isn't simply to collect logs.

The goal is to turn logs into useful information about what is happening in the system.

Basic Monitoring Flow

User
  ↓
Reset Request
  ↓
Application / API
  ↓
Request Logged
  ↓
Log Monitoring
  ↓
Pattern Detection
  ↓
Alert / Investigation

What I Learned

One important takeaway from this task is that logging and monitoring are different things.

Logging records what happened.

Monitoring helps us understand whether something unusual is happening.

For example:

Log:
Password reset requested from IP X.X.X.X

Monitoring:
50 reset requests from the same IP in 2 minutes

The second piece of information is much more useful for detecting suspicious activity.

Security Considerations

When monitoring reset requests, logs should also be handled carefully.

Sensitive information such as:

Passwords
Reset tokens
Authentication secrets
Personal information

should not be unnecessarily stored in plain text logs.

Logs should be protected and access should be limited to authorized users.

Key Takeaway

A reset-password feature may look like a small part of an application, but its logs can provide valuable security and operational information.

Logs → Monitoring → Patterns → Detection → Action

This task helped me understand how monitoring can provide visibility into application activity and help identify unusual behavior before it becomes a bigger problem.

Next, I want to explore how automated alerts and rate limiting can be used to respond to suspicious reset request patterns.

#DevOps #CyberSecurity #ServerMonitoring #Logging #BackendDevelopment #WebSecurity #SoftwareEngineering #Observability #Learning

What I Learned About Publishing an iPhone App on the App Store

Beny — Tue, 25 Aug 2026 14:26:00 +0000

Publishing an iPhone app isn't simply:

Build → Upload → Published ❌

There is an entire review and compliance process behind getting an app onto the App Store.

Today, I explored Apple's guidelines and the important things developers need to consider before submitting an iOS application.

🔍 What I Learned

1. The App Must Be Complete

Before submission, the app should be properly tested and shouldn't contain:

Major bugs or crashes
Placeholder content
Broken features
Non-working links
Unavailable backend services

A working build is the starting point.

2. Privacy Matters 🔐

Developers need to clearly understand what data their application collects and how that data is used.

Important requirements include:

Privacy policy
App privacy information
Data collection details
Tracking information where applicable

3. App Store Metadata Must Be Accurate

The information shown to users should represent the actual application.

This includes:

App Name → Description → Keywords → Screenshots → Category → Age Rating

The metadata shouldn't make claims about features that the app doesn't actually provide.

4. Testing Before Submission

Before sending the app for review, developers should test it properly.

Apple's TestFlight can be used to distribute beta versions to testers and identify issues before the final submission.

5. App Review Information

If an app requires login, reviewers need a way to access it.

Developers may need to provide:

Demo account
Login credentials
Review instructions
Information about important or hidden features

This helps the review team properly evaluate the application.

6. Business & Payment Requirements 💳

Apps containing paid features, subscriptions, or In-App Purchases need to follow Apple's business and payment requirements.

Developers also need to complete the required agreements and financial information in App Store Connect when applicable.

Develop App
    ↓
Test on Real Devices
    ↓
Test with TestFlight
    ↓
Create App in App Store Connect
    ↓
Upload Build
    ↓
Complete Metadata & Privacy
    ↓
Submit for App Review
    ↓
Apple Review
    ↓
Approved 🎉
    ↓
App Store Release

💡 My Key Takeaway

The biggest thing I learned is that App Store publishing is not just a technical process.

A successful submission requires:

Functionality + Privacy + Design + Security + Business + Legal Compliance

The best approach is to consider Apple's requirements while developing the application, rather than trying to fix everything just before submission.

I'm looking forward to learning more about the complete iOS deployment process, especially App Store Connect, TestFlight, certificates, provisioning profiles, and app signing. 🚀

#iOS #AppDevelopment #AppStore #Apple #AppStoreConnect #MobileDevelopment #SoftwareDevelopment #DevOps #Learning

Deploying My First Web Server with Nginx

Beny — Sun, 23 Aug 2026 06:37:16 +0000

Today I worked on a simple but important DevOps task: deploying a web server using Nginx on Ubuntu.

Instead of only learning the theory, I wanted to understand the practical flow of how a web server receives a request and serves a webpage.

What I Did

Installed and verified Nginx
Started the Nginx service
Checked the server status
Tested the server using curl
Created a custom HTML webpage
Served the webpage through Nginx
Accessed the webpage using http://localhost

Simple Architecture

Browser
   ↓
HTTP Request
   ↓
Nginx Web Server
   ↓
/var/www/html/index.html
   ↓
HTML Response
   ↓
Webpage

Commands I Used

nginx -v

sudo service nginx start

sudo service nginx status

curl http://localhost

sudo nginx -t

sudo service nginx reload

What I Built

For the practical demonstration, I created a simple web page and served it using Nginx.

The page was placed in:

/var/www/html/index.html

After configuring the page, I verified the Nginx configuration and accessed it through:

http://localhost

What I Learned 💡

This task helped me understand that deploying a webpage involves more than just writing HTML.

The basic flow is:

Browser → HTTP Request → Nginx → HTML File → Response

I also got practical experience with Linux services, Nginx configuration, the web root directory, and testing a web server from the terminal.

Key Takeaway

A simple Nginx deployment gave me a better understanding of the infrastructure layer behind web applications.

Next, I want to explore how Nginx can be used as a reverse proxy for backend applications. 🚀

#Nginx #DevOps #WebServer #Linux #Ubuntu #CloudComputing #BackendDevelopment #WebDevelopment #SoftwareEngineering

Learning Network Troubleshooting: Checking IP Address and Connectivity

Beny — Fri, 21 Aug 2026 10:38:13 +0000

Today, I worked on a fundamental networking task: checking the IP address of my system and testing network connectivity using practical commands in Windows Command Prompt.

At first, commands like ipconfig and ping seemed very simple. But after implementing them practically, I understood that these commands can help identify where a network problem is actually occurring.

I started with:

ipconfig

This helped me check my system's IPv4 address, subnet mask, and default gateway.

Next, I tested the local network stack using:

ping 127.0.0.1

The result confirmed that my local TCP/IP networking stack was working correctly.

One interesting part of the task was testing:

ping 192.168.1.1

The request timed out. Instead of immediately assuming there was a network problem, I checked my actual network configuration and realized that 192.168.1.1 was not the default gateway of my current network.

This was an important practical lesson for me: we should not assume that every network uses 192.168.1.1 as its gateway. We should first check the actual default gateway using ipconfig.

Finally, I tested external connectivity and DNS resolution using:

ping google.com

The successful response confirmed that my system could communicate with an external network and that DNS resolution was also working.

My Main Takeaway

Today's task helped me understand that network troubleshooting should follow a logical process.

First, check the IP configuration. Then test the local network stack, verify the actual default gateway, test external connectivity, and finally check DNS resolution.

The most important thing I learned is that troubleshooting is not about randomly running commands. Each command helps test a different part of the network.

A simple practical task, but it gave me a much clearer understanding of how to identify whether a connectivity problem is related to the device, local network, gateway, internet connection, or DNS.

#Networking #NetworkTroubleshooting #WindowsCMD #Linux #DevOps #ITInfrastructure #IPAddress #LearningInPublic #TechLearning

Physical Server vs Cloud Server: What I Learned About Infrastructure

Beny — Thu, 20 Aug 2026 14:43:34 +0000

When we build an application, we often focus on the frontend, backend, APIs, and databases.

But there is another important question:

Where should the application actually run?

Today, I spent some time learning about the differences between physical servers and cloud servers.

Initially, I thought the decision was quite simple:

Limited users = Physical Server

More users = Cloud Server

But after exploring the topic further and looking at real-world examples such as Netflix, Dropbox, Meta, and 37signals, I realized that infrastructure decisions are much more complex.

The right choice depends on several factors, including:

Cost and total cost of ownership
CPU, RAM, and storage requirements
Number of users and traffic patterns
Scalability and future growth
Performance and availability
Security and maintenance
Level of infrastructure control required

One of the most important things I learned is that cloud infrastructure is not automatically cheaper, and physical infrastructure is not automatically outdated.

For stable and predictable workloads, physical infrastructure can still be a practical option. On the other hand, for applications with rapidly growing or unpredictable workloads, cloud infrastructure can provide greater flexibility to scale resources when required.

I also found the real-world examples particularly interesting. Different companies make different infrastructure decisions based on their own technical and business requirements, and some even use a hybrid approach that combines physical infrastructure with cloud services.

My Biggest Takeaway

The best infrastructure is not necessarily the most powerful or the most expensive. It is the infrastructure that provides the right balance of cost, performance, scalability, reliability, and control for the application.

This was a really interesting topic to explore, and it changed my initial understanding of how companies should choose between physical and cloud infrastructure.

What do you think?

If you were building a new application with unpredictable growth, would you start with a physical server, a single cloud VM, or design for scalability from the beginning?

#CloudComputing #DevOps #CloudArchitecture #ServerInfrastructure #BackendDevelopment #SoftwareEngineering #Scalability #WebDevelopment #Infrastructure #LearningInPublic

Physical Server vs Cloud Server: Which Infrastructure Makes More Sense?

Beny — Thu, 20 Aug 2026 06:23:06 +0000

When building an application, we usually focus on the frontend, backend, APIs, and database.

But there is another important question:

Where should the application actually run?

Two common approaches are physical servers and cloud/virtual servers. Understanding the difference is important because infrastructure decisions affect scalability, availability, security, maintenance, and cost.

What Is a Server?

A server is a computer system that runs applications, processes requests, communicates with databases, and provides information to users.

A typical request might look like:

User → Internet → Application Server → Backend → Database → Response

Depending on the application, the server may handle authentication, APIs, user data, file processing, notifications, and other backend operations.

In simple terms, the server provides the execution environment behind the application.

Physical Server: More Control, Less Flexibility

A physical server is a dedicated machine used to run applications.

For example:

16 CPU cores + 64 GB RAM + 2 TB SSD

Advantages:

• Dedicated hardware
• Predictable performance
• Greater hardware-level control
• Suitable for stable workloads

Limitations:

• Higher initial investment
• Hardware maintenance
• Hardware failures can cause downtime
• Scaling requires additional or upgraded hardware

If an application suddenly grows beyond the capacity of the machine, increasing capacity may require purchasing and configuring new hardware.

Cloud / Virtual Server: Infrastructure That Can Adapt

A cloud server is a virtual server running on physical infrastructure inside a cloud data center.

For example:

4 vCPU + 16 GB RAM + SSD

Instead of purchasing the entire physical machine, resources can be provisioned according to the application's requirements.

Cloud environments also provide different scaling approaches.

Scale Up:

Increase the resources of an existing server.

4 vCPU → 8 vCPU → 16 vCPU

Scale Out:

Add additional application instances.

Application Server 1 + Application Server 2 + Application Server 3

A load balancer can then distribute incoming traffic between them.

What Happens When Traffic Increases?

Consider an application that normally handles:

1,000 requests/day

After a successful product launch, traffic increases to:

20,000 requests/day

The infrastructure now needs to process significantly more requests.

With a physical server, the available capacity is limited by the installed hardware.

With cloud infrastructure, resources can potentially be increased or additional application instances can be introduced.

The important point is:

Cloud does not automatically solve scalability problems. It provides more flexibility for designing a scalable system.

What Happens When a Server Fails?

A basic architecture may have a single application server connected to the database.

If the only application server fails, the application may become unavailable.

A more resilient architecture can use a load balancer, multiple application servers, a database, and backups.

If one application instance becomes unavailable, traffic can potentially be redirected to another healthy instance.

This is the foundation of high availability.

Running an application in the cloud does not automatically make it highly available. Redundancy must be designed into the architecture.

Security Considerations

Regardless of whether the infrastructure is physical or cloud-based, security remains a major responsibility.

A production environment should consider:

• Authentication and authorization
• Encryption
• Firewalls
• Secure APIs
• Database access control
• Secrets management
• Monitoring and logging
• Backups
• Disaster recovery

Cloud providers offer many security capabilities, but developers still need to configure the application, network, credentials, and data securely.

Applying This to DoctPro

Now let's look at this from a real application perspective.

DoctPro is a healthcare networking platform that connects healthcare professionals and supports services such as professional networking, recruitment, content sharing, and doctor appointments.

Because the platform can grow in terms of users and traffic, infrastructure flexibility becomes important.

A Practical Scenario

Suppose DoctPro initially has:

5,000 active users

Later, after hospital partnerships or recruitment campaigns:

5,000 → 50,000 users

The workload could increase across:

• User authentication
• Healthcare professional searches
• Messaging
• Job searches
• Content
• Appointment requests

With a physical server, hardware may need to be upgraded.

With cloud infrastructure, DoctPro can potentially scale up resources or scale out by adding application instances.

A Practical Cloud Approach for DoctPro

A simple starting architecture could include:

Cloud VM + Database + Backup Storage + Firewall + Monitoring + Logging

As the platform grows, it could gradually evolve toward:

Multiple App Instances → Load Balancer → Auto Scaling → Managed Database → CDN → Disaster Recovery

The advantage of this approach is that complexity can be introduced when the actual workload requires it, rather than building an unnecessarily complicated infrastructure from day one.

Why I Would Choose Cloud for DoctPro

The decision isn't simply:

"Cloud is better than physical servers."

The more important factor is the application's expected growth.

For a platform with changing traffic and multiple services, the ability to scale infrastructure without replacing physical hardware can be a significant advantage.

Therefore, for DoctPro, a cloud-first approach would provide a more flexible foundation for future growth.

Final Thoughts

Choosing infrastructure isn't just about CPU, RAM, or storage.

We also need to consider:

Scalability + Availability + Security + Cost + Maintenance + Future Growth

A physical server provides control and dedicated resources.

Cloud infrastructure provides flexibility and scalability.

For applications with changing workloads, cloud infrastructure can provide more room to evolve.

The best infrastructure isn't necessarily the most powerful one. It's the infrastructure that can evolve with the application.

What would you choose?

For a new application with unpredictable traffic, would you start with a physical server, a single cloud VM, or a scalable cloud architecture?

What would influence your decision most: cost, performance, scalability, security, or simplicity?